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Blue Coat Systems, Inc. utilizes third party software from various sources. Portions of this software are copyrighted by their respective owners as indicated in 
the copyright notices below. 

The following lists the copyright notices for: 

BPF 

Copyright (c) 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996 
The Regents of the University of California. All rights reserved. 

Redistribution and use in source and binary forms, with or without modification, are permitted provided that: (1) source code distributions retain the above 
copyright notice and this paragraph in its entirety, (2) distributions including binary code include the above copyright notice and this paragraph in its entirety 
in the documentation or other materials provided with the distribution, and (3) all advertising materials mentioning features or use of this software display 
the following acknowledgement: 

This product includes software developed by the University of California, Lawrence Berkeley Laboratory and its contributors. 

Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific 
prior written permission. THIS SOFTWARE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT 
LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. 

DES 

Software DES functions written 12 Dec 1986 by Phil Karn, KA9Q; large sections adapted from the 1977 public-domain program by Jim Gillogly. 

EXPAT 

Copyright (c) 1998, 1999, 2000 Thai Open Source Software Center Ltd. 

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the 
Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/ or sell copies of the 
Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: 

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. 

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE 
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS 
OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR 
OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 

Finjan Software 

Copyright (c) 2003 Finjan Software, Inc. All rights reserved. 

Flowerfire 

Copyright (c) 1996-2002 Greg Ferrar 
ISODE 

ISODE 8.0 NOTICE 

Acquisition, use, and distribution of this module and related materials are subject to the restrictions of a license agreement. Consult the Preface in the User's 
Manual for the full terms of this agreement. 

4BSD/ISODE SMP NOTICE 

Acquisition, use, and distribution of this module and related materials are subject to the restrictions given in the file SMP-READ-ME. 

UNIX is a registered trademark in the US and other countries, licensed exclusively through X/ Open Company Ltd. 

MD5 
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RSA Data Security, Inc. MD5 Message-Digest Algorithm 

Copyright (c) 1991-2, RSA Data Security, Inc. Created 1991. All rights reserved. 

License to copy and use this software is granted provided that it is identified as the "RSA Data Security, Inc. MD5 Message-Digest Algorithm" in all material 
mentioning or referencing this software or this function. 

License is also granted to make and use derivative works provided that such works are identified as "derived from the RSA Data Security, Inc. MD5 
Message-Digest Algorithm" in all material mentioning or referencing the derived work. 

RSA Data Security, Inc. makes no representations concerning either the merchantability of this software or the suitability of this software for any particular 
purpose. It is provided "as is" without express or implied warranty of any kind. 

THE BEER-WARE LICENSE" (Revision 42): 

< phk@FreeBSD.org <mailto:phk@FreeBSD.org> > wrote this file. As long as you retain this notice you can do whatever you want with this stuff. If we meet 
some day, and you think this stuff is worth it, you can buy me a beer in return. Poul-Henning Kamp 
Microsoft Windows Media Streaming 

Copyright (c) 2003 Microsoft Corporation. All rights reserved. 

Novell and eDirectory are [either] registered trademarks [or] trademarks of Novell, Inc. in the United States and other countries. 

LDAPSDK.DLL Copyright (c) 2006 Novell, Inc. All rights reserved. 

LDAPSSL.DLL Copyright (c) 2006 Novell, Inc. All rights reserved. 

LDAPX.DLL Copyright (c) 2006 Novell, Inc. All rights reserved. 

The following are copyrights and licenses included as part of Novell's LDAP Libraries for C: 

HSpencer 

Copyright 1992, 1993, 1994 Henry Spencer. All rights reserved. 

This software is not subject to any license of the American Telephone and Telegraph Company or of the Regents of the University of California. 

Permission is granted to anyone to use this software for any purpose on any computer system, and to alter it and redistribute it, subject 
to the following restrictions: 

1. The author is not responsible for the consequences of use of this software, no matter how awful, even if they arise from flaws in it. 

2. The origin of this software must not be misrepresented, either by explicit claim or by omission. Since few users ever read sources, credits must appear in 
the documentation. 

3. Altered versions must be plainly marked as such, and must not be misrepresented as being the original software. Since few users ever read sources, credits 
must appear in the documentation. 

4. This notice may not be removed or altered. 



Copyright (c) 1994 

The Regents of the University of California. All rights reserved. 

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/ or 
other materials provided with the distribution. 

3. All advertising materials mentioning features or use of this software must display the following acknowledgement: 

This product includes software developed by the University of California, Berkeley and its contributors. 

4. Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without 
specific prior written permission. 

THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT 
NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO 
EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, 
OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED 
OF THE POSSIBILITY OF SUCH DAMAGE. 

@(#)COPYRIGHT 8.1 (Berkeley) 3/16/94 

OpenLDAP 

Copyright 1998,1999 The OpenLDAP Foundation, Redwood City, California, USA 
All rights reserved. 

Redistribution and use in source and binary forms are permitted only as authorized by the OpenLDAP Public License. A copy of this license is available at 
http: / / www.OpenLDAP.org/license.html or in file LICENSE in the top-level directory of the distribution. 

Individual files and/ or contributed packages may be copyright by other parties and use subject to additional restrictions. 

This work is derived from the University of Michigan LDAP v3.3 distribution. Information concerning is available at 
http:/ / www. umich.edu/ ~dirsvcs/ldap/ldap.html . 

This work also contains materials derived from public sources. 

Additional Information about OpenLDAP can be obtained at: 



IV 



Third Party Copyright Notices 



http:/ 7www.openldap.org/ 
or by sending e-mail to: 
info@OpenLDAP.org 

Portions Copyright (c) 1992-1996 Regents of the University of Michigan. 

All rights reserved. 

Redistribution and use in source and binary forms are permitted provided that this notice is preserved and that due credit is given to the University of 
Michigan at Ann Arbor. The name of the University may not be used to endorse or promote products derived from this software without specific prior written 
permission. This software is provided "as is" without express or implied warranty. 

The OpenLDAP Public License 
Version 2.0.1, 21 December 1999 

Copyright 1999, The OpenLDAP Foundation, Redwood City, California, USA. 

All Rights Reserved. 

Redistribution and use of this software and associated documentation ("Software"), with or without modification, are permitted provided that the following 
conditions are met: 

1. Redistributions of source code must retain copyright statements and notices. Redistributions must also contain a copy of this document. 

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/ or 
other materials provided with the distribution. 

3. The name "OpenLDAP" must not be used to endorse or promote products derived from this Software without prior written permission of the OpenLDAP 
Foundation. For written permission, please contact foundation@openldap.org. 

4. Products derived from this Software may not be called "OpenLDAP" nor may "OpenLDAP" appear in their names without prior written permission of the 
OpenLDAP Foundation. OpenLDAP is a trademark of the OpenLDAP Foundation. 

5. Due credit should be given to the OpenLDAP Project 
( http: / / www.openldap.org/ . 

THIS SOFTWARE IS PROVIDED BY THE OPENLDAP FOUNDATION AND CONTRIBUTORS "AS IS" AND ANY EXPRESSED OR IMPLIED 
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OPENLDAP FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, 

INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT HOWEVER CAUSED AND ON ANY 
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY 
WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 

LICENSE ISSUES 



The OpenSSL toolkit stays under a dual license, i.e. both the conditions of the OpenSSL License and the original SSLeay license apply to the toolkit. See below 
for the actual license texts. Actually both licenses are BSD-style Open Source licenses. In case of any license issues related to OpenSSL please contact 
openssl-core@openssl.org. 

OpenSSL License 



Copyright (c) 1998-2000 The OpenSSL Project. All rights reserved. 

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/ or 
other materials provided with the distribution. 

3. All advertising materials mentioning features or use of this software must display the following acknowledgment: 

"This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit, ( http: / / www.openssl.org / " 

4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to endorse or promote products derived from this software without prior written 
permission. For written permission, please contact openssl-core@openssl.org. 

5. Products derived from this software may not be called "OpenSSL" nor may "OpenSSL" appear in their names without prior written permission of the 
OpenSSL Project. 

6. Redistributions of any form whatsoever must retain the following acknowledgment: 

"This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit ( http:/ / www.openssl.org/ " 

THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT "AS IS” AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT 
SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, 
OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED 
OF THE POSSIBILITY OF SUCH DAMAGE. 



This product includes cryptographic software written by Eric Young (eay@cryptsoft.com). This product includes software written by Tim Hudson 
(tjh@cryptsoft.com). 
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Original SSLeay License 



Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com) 

All rights reserved. 

This package is an SSL implementation written by Eric Young (eay@cryptsoft.com). The implementation was written so as to conform with Netscapes SSL. 

This library is free for commercial and non-commercial use as long as the following conditions are aheared to. The following conditions apply to all code 
found in this distribution, be it the RC4, RSA, lhash, DES, etc., code; not just the SSL code. The SSL documentation included with this distribution is covered 
by the same copyright terms except that the holder is Tim Hudson (tjh@cryptsoft.com). 

Copyright remains Eric Young's, and as such any Copyright notices in the code are not to be removed. If this package is used in a product, Eric Young should 
be given attribution as the author of the parts of the library used. This can be in the form of a textual message at program startup or in documentation (online 
or textual) provided with the package. 

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 

1. Redistributions of source code must retain the copyright notice, this list of conditions and the following disclaimer. 

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/ or 
other materials provided with the distribution. 

3. All advertising materials mentioning features or use of this software must display the following acknowledgement: 

"This product includes cryptographic software written by Eric Young (eay@cryptsoft.com)" 

The word 'cryptographic' can be left out if the rouines from the library being used are not cryptographic related :-). 

4. If you include any Windows specific code (or a derivative thereof) from the apps directory (application code) you must include an acknowledgement: 
"This product includes software written by Tim Hudson (tjh@cryptsoft.com)" 

THIS SOFTWARE IS PROVIDED BY ERIC YOUNG "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE 
AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES 
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING 
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 
DAMAGE. 

The licence and distribution terms for any publically available version or derivative of this code cannot be changed, i.e. this code cannot simply be copied and 
put under another distribution licence [including the GNU Public Licence.] 

[end of copyrights and licenses for Novell's LDAP Libraries for C] 

OpenLDAP 

Copyright (c) 1999-2001 The OpenLDAP Foundation, Redwood City, California, USA. All Rights Reserved. Permission to copy and distribute verbatim 
copies of this document is granted. 

http:/ / www.openldap.org/ software/ release/ license.html 
The OpenLDAP Public License Version 2.7, 7 September 2001 

Redistribution and use of this software and associated documentation ("Software"), with or without modification, are permitted provided that the following 
conditions are met: 

1. Redistributions of source code must retain copyright statements and notices, 

2. Redistributions in binary form must reproduce applicable copyright statements and notices, this list of conditions, and the following disclaimer in the 
documentation and/ or other materials provided with the distribution, and 

3. Redistributions must contain a verbatim copy of this document. 

The OpenLDAP Foundation may revise this license from time to time. Each revision is distinguished by a version number. You may use this Software under 
terms of this license revision or under the terms of any subsequent revision of the license. 

THIS SOFTWARE IS PROVIDED BY THE OPENLDAP FOUNDATION AND ITS CONTRIBUTORS "AS IS" AND ANY EXPRESSED OR IMPLIED 
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OPENLDAP FOUNDATION, ITS CONTRIBUTORS, OR THE AUTHOR(S) OR OWNER(S) OF 
THE SOFTWARE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, 
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR 
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 

The names of the authors and copyright holders must not be used in advertising or otherwise to promote the sale, use or other dealing in this Software 
without specific, written prior permission. Title to copyright in this Software shall at all times remain with copyright holders. 

OpenLDAP is a registered trademark of the OpenLDAP Foundation. 

OpenSSH 

Copyright (c) 1995 Tatu Ylonen <ylo@cs.hut.fi>, Espoo, Finland. All rights reserved 
This file is part of the OpenSSH software. 

The licences which components of this software fall under are as follows. First, we will summarize and say that all components are under a BSD licence, or a 
licence more free than that. 

OpenSSH contains no GPL code. 
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1) As far as I am concerned, the code I have written for this software can be used freely for any purpose. Any derived versions of this software must be clearly 
marked as such, and if the derived work is incompatible with the protocol description in the RFC file, it must be called by a name other than "ssh" or "Secure 
Shell". 

[Tatu continues] 

However, I am not implying to give any licenses to any patents or copyrights held by third parties, and the software includes parts that are not under my 
direct control. As far as I know, all included source code is used in accordance with the relevant license agreements and can be used freely for any purpose 
(the GNU license being the most restrictive); see below for details. 

[However, none of that term is relevant at this point in time. All of these restrictively licenced software components which he talks about have been removed 
from OpenSSH, i.e., 

- RSA is no longer included, found in the OpenSSL library 

- IDEA is no longer included, its use is deprecated 

- DES is now external, in the OpenSSL library 

- GMP is no longer used, and instead we call BN code from OpenSSL 

- Zlib is now external, in a library 

- The make-ssh-known-hosts script is no longer included 

- TSS has been removed 

- MD5 is now external, in the OpenSSL library 

- RC4 support has been replaced with ARC4 support from OpenSSL 

- Blowfish is now external, in the OpenSSL library 
[The licence continues] 

Note that any information and cryptographic algorithms used in this software are publicly available on the Internet and at any major bookstore, scientific 
library, and patent office worldwide. More information can be found e.g. at "http: / / www.cs.hut.fi/ crypto". 

The legal status of this program is some combination of all these permissions and restrictions. Use only at your own responsibility. You will be responsible for 
any legal consequences yourself; I am not making any claims whether possessing or using this is legal or not in your country, and I am not taking any 
responsibility on your behalf. 

NO WARRANTY 

BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY 
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE 
PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED 
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND 
PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY 
SERVICING, REPAIR OR CORRECTION. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY 
COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE 
TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR 
INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES 
SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER 
OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 

2) The 32-bit CRC compensation attack detector in deattack.c was contributed by CORE SDI S.A. under a BSD-style license. 

Cryptographic attack detector for ssh - source code 

Copyright (c) 1998 CORE SDI S.A., Buenos Aires, Argentina. All rights reserved. Redistribution and use in source and binary forms, with or without 
modification, are permitted provided that this copyright notice is retained. THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESS OR IMPLIED 
WARRANTIES ARE DISCLAIMED. IN NO EVENT SHALL CORE SDI S.A. BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 
EXEMPLARY OR CONSEQUENTIAL DAMAGES RESULTING FROM THE USE OR MISUSE OF THIS SOFTWARE. 

Ariel Futoransky <futo@core~sdi.com> chttp:/ / www.core-sdi.com> 

3) ssh-keygen was contributed by David Mazieres under a BSD-style license. 

Copyright 1995, 1996 by David Mazieres <dm@lcs.mit.edu>. Modification and redistribution in source and binary forms is permitted provided that due credit 
is given to the author and the OpenBSD project by leaving this copyright notice intact. 

4) The Rijndael implementation by Vincent Rijmen, Antoon Bosselaers and Paulo Barreto is in the public domain and distributed with the following license: 
@version 3.0 (December 2000) 

Optimised ANSI C code for the Rijndael cipher (now AES) 

@author Vincent Rijmen <vincent.rijmen@esat.kuleuven.ac.be> 

@author Antoon Bosselaers <antoon.bosselaers@esat.kuleuven.ac.be> 

@author Paulo Barreto <paulo.barreto@terra.com.br> 

This code is hereby placed in the public domain. 

THIS SOFTWARE IS PROVIDED BY THE AUTHORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, 
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE 
AUTHORS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES 
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING 
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 
DAMAGE. 
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5) One component of the ssh source code is under a 3-clause BSD license, held by the University of California, since we pulled these parts from original 
Berkeley code. 

Copyright (c) 1983, 1990, 1992, 1993, 1995 

The Regents of the University of California. All rights reserved. 



Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/ or 
other materials provided with the distribution. 

3. Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without 
specific prior written permission. 

THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT 
NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO 
EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, 
OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED 
OF THE POSSIBILITY OF SUCH DAMAGE. 

6) Remaining components of the software are provided under a standard 2-term BSD licence with the following names as copyright holders: 

Markus Friedl 
Theo de Raadt 
Niels Provos 
Dug Song 
Aaron Campbell 
Damien Miller 
Kevin Steves 
Daniel Kouril 
Wesley Griffin 
Per Allansson 
Nils Nordman 
Simon Wilkinson 

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/ or 
other materials provided with the distribution. 

THIS SOFTWARE IS PROVIDED BY THE AUTHOR "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE 
AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT 
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR 
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 

OpenSSL 

Copyright (c) 1995-1998 Eric Young ( eay@cryptsoft.com') . All rights reserved, 
http:/ / www.openssl.org/ about/ 
http:/ / www.openssl.org/ about/ 

OpenSSL is based on the excellent SSLeay library developed by Eric A. Young <mailto:eay@cryptsoft.com> and Tim T. Hudson <mailto:tjh@cryptsoft.com> . 
The OpenSSL toolkit is licensed under a Apache-style license which basically means that you are free to get and use it for commercial and non-commercial 
purposes. 

This package is an SSL implementation written by Eric Young ( eay@cryptsoft.com) . The implementation was written so as to conform with Netscapes SSL. 
This library is free for commercial and non-commercial use as long as the following conditions are adhered to. The following conditions apply to all code 
found in this distribution, be it the RC4, RSA, lhash, DES, etc., code; not just the SSL code. The SSL documentation included with this distribution is covered 
by the same copyright terms except that the holder is Tim Hudson (tjh@cryptsoft.com) . 

Copyright remains Eric Young's, and as such any Copyright notices in the code are not to be removed. If this package is used in a product, Eric Young should 
be given attribution as the author of the parts of the library used. This can be in the form of a textual message at program startup or in documentation (online 
or textual) provided with the package. 

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 

1. Redistributions of source code must retain the copyright notice, this list of conditions and the following disclaimer. 

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/ or 
other materials provided with the distribution. 
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3. All advertising materials mentioning features or use of this software must display the following acknowledgement: "This product includes cryptographic 
software written by Eric Young (eay@cryptsoft.com)" The word 'cryptographic' can be left out if the routines from the library being used are not cryptographic 
related 

4. If you include any Windows specific code (or a derivative thereof) from the apps directory (application code) you must include an acknowledgement: "This 
product includes software written by Tim Hudson (tjh@cryptsoft.com)" 

THIS SOFTWARE IS PROVIDED BY ERIC YOUNG "AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE 
AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES 
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING 
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 
DAMAGE. 

The license and distribution terms for any publicly available version or derivative of this code cannot be changed, i.e. this code cannot simply be copied and 
put under another distribution license [including the GNU Public License.] 

Copyright (c) 1998-2002 The OpenSSL Project. All rights reserved. 

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/ or 
other materials provided with the distribution. 

3. All advertising materials mentioning features or use of this software must display the following acknowledgment: 

"This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit, (http:/ / www.openssl.org/)" 

4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to endorse or promote products derived from this software without prior written 
permission. For written permission, please contact openssl-core@openssl.org. 

5. Products derived from this software may not be called "OpenSSL" nor may "OpenSSL" appear in their names without prior written permission of the 
OpenSSL Project. 

6. Redistributions of any form whatsoever must retain the following acknowledgment: "This product includes software developed by the OpenSSL Project for 
use in the OpenSSL Toolkit (http:/ / www.openssl.org/)" 

THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT "AS IS" AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT 
SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, 
OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED 
OF THE POSSIBILITY OF SUCH DAMAGE. 

This product includes cryptographic software written by Eric Young (eay@cryptsoft.com). This product includes software written by Tim Hudson 
(tjh@cryptsoft.com) . 

PCRE 

Copyright (c) 1997-2001 University of Cambridge 

University of Cambridge Computing Service, Cambridge, England. Phone: +44 1223 334714. 

Written by: Philip Hazel <phlO@cam.ac.uk> 

Permission is granted to anyone to use this software for any purpose on any computer system, and to redistribute it freely, subject to the following restrictions: 

1. This software is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of 
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 

2. Regular expression support is provided by the PCRE library package, which is open source software, written by Philip Hazel, and copyright by the 
University of Cambridge, England. 

ftp:/ / ftp.csx.cam.ac.uk/ pub /software /programming/ pcre/ 

PHAOS SSLava and SSLavaThin 

Copyright (c) 1996-2003 Phaos Technology Corporation. All Rights Reserved. 

The software contains commercially valuable proprietary products of Phaos which have been secretly developed by Phaos, the design and development of 
which have involved expenditure of substantial amounts of money and the use of skilled development experts over substantial periods of time. The software 
and any portions or copies thereof shall at all times remain the property of Phaos. 

PHAOS MAKES NO WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION THE IMPLIED WARRANTY OF MERCHANTABILITY 
OR FITNESS FOR A PARTICULAR PURPOSE, REGARDING THE SOFTWARE, OR ITS USE AND OPERATION ALONE OR IN COMBINATION WITH 
ANY OTHER SOFTWARE. 

PHAOS SHALL NOT BE LIABLE TO THE OTHER OR ANY OTHER PERSON CLAIMING DAMAGES AS A RESULT OF THE USE OF ANY PRODUCT OR 
SOFTWARE FOR ANY DAMAGES WHATSOEVER. IN NO EVENT WILL PHAOS BE LIABLE FOR SPECIAL, INCIDENTAL OR CONSEQUENTIAL 
DAMAGES, EVEN IF ADVISED OF THE POSSIBLITY OF SUCH DAMAGES. 

RealSystem 

The RealNetworks® RealProxy™ Server is included under license from RealNetworks, Inc. Copyright 1996-1999, RealNetworks, Inc. All rights reserved. 
SNMP 

Copyright (C) 1992-2001 by SNMP Research, Incorporated. 
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This software is furnished under a license and may be used and copied only in accordance with the terms of such license and with the inclusion of the above 
copyright notice. This software or any other copies thereof may not be provided or otherwise made available to any other person. No title to and ownership of 
the software is hereby transferred. The information in this software is subject to change without notice and should not be construed as a commitment by 
SNMP Research, Incorporated. 

Restricted Rights Legend: 

Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(h) of the Rights in Technical Data and Computer 
Software clause at DFARS 252.227-7013; subparagraphs (c)(4) and (d) of the Commercial Computer Software-Restricted Rights Clause, FAR 52.227-19; and in 
similar clauses in the NASA FAR Supplement and other corresponding governmental regulations. 

PROPRIETARY NOTICE 

This software is an unpublished work subject to a confidentiality agreement and is protected by copyright and trade secret law. Unauthorized copying, 
redistribution or other use of this work is prohibited. The above notice of copyright on this source code product does not indicate any actual or intended 
publication of such source code. 

STLport 

Copyright (c) 1999, 2000 Boris Fomitchev 

This material is provided "as is", with absolutely no warranty expressed or implied. Any use is at your own risk. 

Permission to use or copy this software for any purpose is hereby granted without fee, provided the above notices are retained on all copies. Permission to 
modify the code and to distribute modified code is granted, provided the above notices are retained, and a notice that the code was modified is included with 
the above copyright notice. 

The code has been modified. 

Copyright (c) 1994 Hewlett-Packard Company 

Copyright (c) 1996-1999 Silicon Graphics Computer Systems, Inc. 

Copyright (c) 1997 Moscow Center for SPARC Technology 

Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby granted without fee, provided that the 
above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. 
Hewlett-Packard Company makes no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied 
warranty. 

Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby granted without fee, provided that the 
above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. Silicon 
Graphics makes no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty. 

Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby granted without fee, provided that the 
above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. Moscow 
Center for SPARC Technology makes no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied 
warranty. 

SmartFilter 

Copyright (c) 2003 Secure Computing Corporation. All rights reserved. 

SurfControl 

Copyright (c) 2003 SurfControl, Inc. All rights reserved. 

Symantec AntiVirus Scan Engine 

Copyright (c) 2003 Symantec Corporation. All rights reserved. 

TCPIP 

Some of the files in this project were derived from the 4.X BSD (Berkeley Software Distribution) source. 

Their copyright header follows: 

Copyright (c) 1982, 1986, 1988, 1990, 1993, 1994, 1995 

The Regents of the University of California. All rights reserved. 

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/ or 
other materials provided with the distribution. 

3. All advertising materials mentioning features or use of this software must display the following acknowledgement: 

This product includes software developed by the University of California, Berkeley and its contributors. 

4. Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without 
specific prior written permission. 

THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT 
NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO 
EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, 
OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED 
OF THE POSSIBILITY OF SUCH DAMAGE. 

Trend Micro 

Copyright (c) 1989-2003 Trend Micro, Inc. All rights reserved. 
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zlib 

Copyright (c) 2003 by the Open Source Initiative 

This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of 
this software. 

ICU License - ICU 1.8.1 and later COPYRIGHT AND PERMISSION NOTICE Copyright (c) 1995-2003 International Business Machines Corporation and others 
All rights reserved. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the 
"Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, and/or sell 
copies of the Software, and to permit persons to whom the Software is furnished to do so, provided that the above copyright notice(s) and this permission 
notice appear in all copies of the Software and that both the above copyright notice(s) and this permission notice appear in supporting documentation. THE 
SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE 
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO 
EVENT SHALL THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL INDIRECT 
OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN 
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR 
PERFORMANCE OF THIS SOFTWARE. Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to 
promote the sale, use or other dealings in this Software without prior written authorization of the copyright holder 
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The SG Client software is based in part on the work of the Independent JPEG Group 
The SG Client software is based in part on the work of the FreeType Project (www.freetype.org) 
The SG Client software is based in part on the work of Chris Maunder and info-zip 
LEGAL ISSUES 



In plain English: 

1. We don’t promise that this software works. (But if you find any bugs, please let us know!) 

2. You can use this software for whatever you want. You don't have to pay us. 

3. You may not pretend that you wrote this software. If you use it in a program, you must acknowledge somewhere in your documentation that 
you've used the IJG code. 

In legalese: 

The authors make NO WARRANTY or representation, either express or implied, with respect to this software, its quality, accuracy, merchantability, or fitness 
for a particular purpose. This software is provided "AS IS", and you, its user, assume the entire risk as to its quality and accuracy. 

This software is copyright (C) 1991-1998, Thomas G. Lane. All Rights Reserved except as specified below. 

Permission is hereby granted to use, copy, modify, and distribute this software (or portions thereof) for any purpose, without fee, subject to these conditions: 

(1) If any part of the source code for this software is distributed, then this README file must be included, with this copyright and no-warranty notice 
unaltered; and any additions, deletions, or changes to the original files must be clearly indicated in accompanying documentation. (2) If only executable code 
is distributed, then the accompanying documentation must state that "this software is based in part on the work of the Independent JPEG Group". (3) 
Permission for use of this software is granted only if the user accepts full responsibility for any undesirable consequences; the authors accept NO LIABILITY 
for damages of any kind. 

These conditions apply to any software derived from or based on the IJG code, not just to the unmodified library. If you use our work, you ought to 
acknowledge us. 

Permission is NOT granted for the use of any IJG author's name or company name in advertising or publicity relating to this software or products derived 
from it. This software may be referred to only as "the Independent JPEG Group's software". 

We specifically permit and encourage the use of this software as the basis of commercial products, provided that all warranty or liability claims are assumed 
by the product vendor. 

ansi2knr.c is included in this distribution by permission of L. Peter Deutsch, sole proprietor of its copyright holder, Aladdin Enterprises of Menlo Park, CA. 
ansi2knr.c is NOT covered by the above copyright and conditions, but instead by the usual distribution terms of the Free Software Foundation; principally, 
that you must include source code if you redistribute it. (See the file ansi2knr.c for full details.) However, since ansi2knr.c is not needed as part of any 
program generated from the IJG code, this does not limit you more than the foregoing paragraphs do. 

The Unix configuration script "configure" was produced with GNU Autoconf. It is copyright by the Free Software Foundation but is freely distributable. The 
same holds for its supporting scripts (config.guess, config.sub, ltconfig, ltmain.sh). Another support script, install-sh, is copyright by M.I.T. but is also freely 
distributable. 

It appears that the arithmetic coding option of the JPEG spec is covered by patents owned by IBM, AT&T, and Mitsubishi. Hence arithmetic coding cannot 
legally be used without obtaining one or more licenses. For this reason, support for arithmetic coding has been removed from the free JPEG software. (Since 
arithmetic coding provides only a marginal gain over the unpatented Huffman mode, it is unlikely that very many implementations will support it.) So far as 
we are aware, there are no patent restrictions on the remaining code. 

The IJG distribution formerly included code to read and write GIF files. To avoid entanglement with the Unisys LZW patent, GIF reading support has been 
removed altogether, and the GIF writer has been simplified to produce "uncompressed GIFs". This technique does not use the LZW algorithm; the resulting 
GIF files are larger than usual, but are readable by all standard GIF decoders. 

We are required to state that "The Graphics Interchange Format(c) is the Copyright property of CompuServe Incorporated. GIF(sm) is a Service Mark 
property of CompuServe Incorporated." 



The FreeType Project LICENSE 
2006-Jan-27 

Copyright 1996-2002, 2006 by David Turner, Robert Wilhelm, and Werner Lemberg 
Introduction 



The FreeType Project is distributed in several archive packages; some of them may contain, in addition to the FreeType font engine, various tools and 
contributions which rely on, or relate to, the FreeType Project. 

This license applies to all files found in such packages, and which do not fall under their own explicit license. The license affects thus the FreeType font 
engine, the test programs, documentation and makefiles, at the very least. 

This license was inspired by the BSD, Artistic, and IJG (Independent JPEG Group) licenses, which all encourage inclusion and use of free software in 
commercial and freeware products alike. As a consequence, its main points are that: 

o We don't promise that this software works. However, we will be interested in any kind of bug reports, ('as is' distribution) 
o You can use this software for whatever you want, in parts or full form, without having to pay us. ('royalty-free' usage) 

o You may not pretend that you wrote this software. If you use it, or only parts of it, in a program, you must acknowledge somewhere in your 
documentation that you have used the FreeType code, ('credits') 

We specifically permit and encourage the inclusion of this software, with or without modifications, in commercial products. We disclaim all warranties 
covering The FreeType Project and assume no liability related to The FreeType Project. 
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Finally, many people asked us for a preferred form for a credit/ disclaimer to use in compliance with this license. We thus encourage you to use the 
following text: 

"Portions of this software are copyright (c) 2007The FreeType Project (www.freetype.org). All rights reserved." 

Legal Terms 



0. Definitions 

Throughout this license, the terms 'package', 'FreeType Project', and 'FreeType archive’ refer to the set of files originally distributed by the authors (David 
Turner, Robert Wilhelm, and Werner Lemberg) as the 'FreeType Project', be they named as alpha, beta or final release. 

'You' refers to the licensee, or person using the project, where 'using' is a generic term including compiling the project's source code as well as linking it to 
form a 'program' or 'executable'. This program is referred to as 'a program using the FreeType engine’. 

This license applies to all files distributed in the original FreeType Project, including all source code, binaries and documentation, unless otherwise 
stated in the file in its original, unmodified form as distributed in the original archive. If you are unsure whether or not a particular file is covered by this 
license, you must contact us to verify this. 

The FreeType Project is copyright (C) 1996-2000 by David Turner, Robert Wilhelm, and Werner Lemberg. All rights reserved except as specified below. 

1. No Warranty 

THE FREETYPE PROJECT IS PROVIDED 'AS IS' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT 
LIMITED TO, WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT WILL ANY OF THE 
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY DAMAGES CAUSED BY THE USE OR THE INABILITY TO USE, OF THE FREETYPE 
PROJECT. 

2. Redistribution 

This license grants a worldwide, royalty-free, perpetual and irrevocable right and license to use, execute, perform, compile, display, copy, create 
derivative works of, distribute and sublicense the FreeType Project (in both source and object code forms) and derivative works thereof for any purpose; 
and to authorize others to exercise some or all of the rights granted herein, subject to the following conditions: 

o Redistribution of source code must retain this license file ('FTL.TXT') unaltered; any additions, deletions or changes to the original files must be clearly 
indicated in accompanying documentation. The copyright notices of the unaltered, original files must be preserved in all copies of source files. 

o Redistribution in binary form must provide a disclaimer that states that the software is based in part of the work of the FreeType Team, in the distribution 
documentation. We also encourage you to put an URL to the FreeType web page in your documentation, though this isn't mandatory. 

These conditions apply to any software derived from or based on the FreeType Project, not just the unmodified files. If you use our work, you must 
acknowledge us. However, no fee need be paid to us. 

3. Advertising 

Neither the FreeType authors and contributors nor you shall use the name of the other for commercial, advertising, or promotional purposes without 
specific prior written permission. 

We suggest, but do not require, that you use one or more of the following phrases to refer to this software in your documentation or advertising materials: 
'FreeType Project', 'FreeType Engine’, 'FreeType library', or 'FreeType Distribution'. 

As you have not signed this license, you are not required to accept it. However, as the FreeType Project is copyrighted material, only this license, or 
another one contracted with the authors, grants you the right to use, distribute, and modify it. Therefore, by using, distributing, or modifying the 
FreeType Project, you indicate that you understand and accept all the terms of this license. 

4. Contacts 

There are two mailing lists related to FreeType: 
o freetype@nongnu.org 

Discusses general use and applications of FreeType, as well as future and wanted additions to the library and distribution. If you are looking for support, 
start in this list if you haven't found anything to help you in the documentation, 
o freetype-devel@nongnu.org 

Discusses bugs, as well as engine internals, design issues, specific licenses, porting, etc. 

Our home page can be found at http: / / www.freetype.org 



zip . cpp — which is used by the Data Collector utility included in the SG Client software — is almost entirely based upon code by info-zip. It has been 
modified by Lucian Wischik. The modifications were a complete rewrite of the bit of code that generates the layout of the zipfile, and support for zipping 
tofrom memory or handles or pipes or pagefile or diskfiles, encryption, Unicode. 

The original code may be found at http:www.info-zip.org. The original copyright text follows. 

This is version 1999-Oct-05 of the Info-ZIP copyright and license. 

The definitive version of this document should be available at ftp:ftp.cdrom.compubinfoziplicense.html indefinitely. 

Copyright (c) 1990-1999 Info-ZIP. All rights reserved. 

For the purposes of this copyright and license, "Info-ZIP" is defined as the following set of individuals: 

Mark Adler, John Bush, Karl Davis, Harald Denker, Jean-Michel Dubois, Jean-loup Gailly, Hunter Goatley, Ian Gorman, Chris Herborth, Dirk Haase, Greg 
Hartwig, Robert Heath, Jonathan Hudson, Paul Kienitz, David Kirschbaum, Johnny Lee, Onno van der Linden, Igor Mandrichenko, Steve P. Miller, Sergio 
Monesi, Keith Owens, George Petrov, Greg Roelofs, Kai Uwe Rommel, Steve Salisbury, Dave Smith, Christian Spieler, Antoine Verheijen, Paul von Behren, 
Rich Wales, Mike White 

This software is provided "as is," without warranty of any kind, express or implied. In no event shall Info-ZIP or its contributors be held liable for any direct, 
indirect, incidental, special or consequential damages arising out of the use of or inability to use this software. 
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Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the 
following restrictions: 

1. Redistributions of source code must retain the above copyright notice, definition, disclaimer, and this list of conditions. 

2. Redistributions in binary form must reproduce the above copyright notice, definition, disclaimer, and this list of conditions in documentation andor other 
materials provided with the distribution. 

3. Altered versions—including, but not limited to, ports to new operating systems, existing ports with new graphical interfaces, and dynamic, shared, or static 
library versions—must be plainly marked as such and must not be misrepresented as being the original source. Such altered versions also must not be 
misrepresented as being Info-ZIP releases— including, but not limited to, labeling of the altered versions with the names "Info-ZIP" (or any variation thereof, 
including, but not limited to, different capitalizations), "Pocket UnZip," "WiZ" or "MacZip" without the explicit permission of Info-ZIP. Such altered versions 
are further prohibited from misrepresentative use of the Zip-Bugs or Info-ZIP e-mail addresses or of the Info-ZIP URL(s). 

4. Info-ZIP retains the right to use the names "Info-ZIP," "Zip," "UnZip," "WiZ," "Pocket UnZip," "Pocket Zip," and "MacZip" for its own source and binary 
releases. 

Written by Chris Maunder (cmaunder@mail.com) Copyright (c) 1998-2003. 

This code may be used in compiled form in any way you desire. This file may be redistributed unmodified by any means PROVIDING it is not sold for profit 
without the authors written consent, and providing that this notice and the authors name is included. If the source code in this file is used in any commercial 
application then acknowledgement must be made to the author of this file (in whatever form you wish). 

This file is provided "as is" with no expressed or implied warranty. The author accepts no liability for any damage caused through use. 
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Chapter 1: Introducing the ProxySG 



Blue Coat® Systems ProxySG 1 Appliance represents the latest in perimeter defense for securing and 
controlling Web-based content and applications. The Blue Coat ProxySG is designed to integrate 
protection and control functions for Internet and intranet traffic without sacrificing performance and 
employee productivity 

The ProxySG series of proxy appliances is designed specifically to manage and control user 
communication over the Internet. Acting on behalf of the user and the application, the ProxySG does 
not replace existing perimeter security devices; rather, it complements them by giving organizations 
the ability to control communications in a number of ways that firewalls and other externally focused 
devices cannot. 

Web Security Solution 

The Blue Coat ProxySG provides a point of integration, control, and acceleration for enterprise Web 
security applications, including: 

D Layered security approach with content-level protection to combat Web-based threats using port 
80. 

□ Abundant policy controls wrapped in performance-based hardware and a custom operating 
system to give organizations visibility and control over employee Web communications. 

□ A preventative spyware defense that combines multiple techniques in a high-performance 
solution acceptable for Web-based business communications. 

□ Integrated reverse proxy caching and SSL support to offload content delivery and encryption 
tasks from Web servers, reducing server bottlenecks and enhancing Web site performance and 
scalability. 

□ Control over which users are allowed to use Instant Messaging, and which IM protocols are 
allowed, what features are to be enabled, to whom users may IM or chat with (inside the company 
or outside the company), what time of the day they can IM, and how logging is managed. 

□ Immediate and dynamic Peer-to-Peer (P2P) control, allowing an administrator to identify, log, and 
block P2P traffic. 

□ Integrated caching, content positioning, bandwidth savings, and bandwidth management to 
provide superior performance for controlling Web content. 

□ Control over Windows Media, RealTime, and QuickTime video and audio streams as the file is 
being downloaded over the Internet. 

n Prevention of the spread of viruses and other malicious code by using the Blue Coat ProxyAV™ 
Appliance in conjunction with the Blue Coat ProxySG. The ProxySG with ProxyAV integration is a 
high-performance Web anti-virus (AV) solution. 
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□ Control over the type of content retrieved by the ProxySG. You can also filter requests made by 
clients. If you use Blue Coat Web Filter (BCWF), a highly effective content filtering service that 
quickly learns and adapts to the working set of its users, you can also use a network service that 
dynamically examines and categorizes Web pages as they are requested. 

Ease of Deployment 

The ProxySG is specifically designed to increase security and reduce costs associated with central, 
regional, and branch office Web protection. For example, the SG200 and SG400 platforms easily drop in 
to remote environments where technical support staff is not always available, and features simple 
installation and remote management. 

Other platforms also feature a simple-to-manage system that installs in minutes with little ongoing 
maintenance. In addition, they also provide configuration restoration that allows system 
configuration to be archived, including all system settings, filtering and policies; removable, 
hot-swappable disk drives for true fault tolerance, and are field serviceable and upgradeable. 

Policy and Management Architecture 

Networking environments have become increasingly complex, with a variety of security and access 
management issues. Enterprises face challenges in configuring products and ensuring the result 
supports enterprise policies. Policies enhance ProxySG features, such as authentication and virus 
scanning, allowing you to manage Web access specific to the enterprise's needs. 

Blue Coat policies provide: 

□ Fine-grained control over various aspects of ProxySG behavior. 

□ Multiple policy decisions for each request. 

□ Multiple actions triggered by a particular condition. 

□ Bandwidth limits. 

□ Authentication awareness, including user and group configuration. 

□ Flexibility of user-defined conditions and actions. 

□ Convenience of predefined common actions and transformations. 

□ Support for multiple authentication realms. 

□ Configurable policy event logging. 

□ Built-in debugging. 

The ProxySG uses policies and system configuration together to provide the best possible security for 
your network environment. 

Blue Coat's unique architecture allows for scalable decision making. Effectively turning on multiple 
combinations of granular policy requires a unique level of performance. 

Blue Coat's flexible logging features, coupled with integrated authentication and identification 
capabilities, give organizations the power to monitor Web access for every user in the network at any 
time, regardless of where they are. Internet access traffic flowing through the ProxySG gives 
administrators and managers the ability to audit Web traffic as needed. 
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Content Filtering 

As the number of users and the total amount of traffic grows, policy enforcement demands higher 
performance to provide adequate end-user quality of experience. To satisfy the management level and 
scalability that enterprise traffic demands, ProxySG Appliances have emerged as a new layer of 
infrastructure that provide the performance and manageability required for enterprise-wide 
policy-based content filtering. 

SGOS 4.1offers a dynamic categorization service if you use the Blue Coat Web Filter (BCWF). The 
BCWF categorization service is an Internet service, available from designated service points with 
high-bandwidth connections and dedicated hardware. It analyzes data externally so that content 
(offensive, distasteful, or perhaps even potentially a legal liability) never enters the network. 




Figure 1-1: Content Filtering 

The ProxySG enforces Internet access policies based on: 

□ Content categories (gambling, sex, etc.) — Besides BCWF, which includes a database and a 
dynamic categorization service, databases from leading third-party filtering vendors are offered. 

□ Content type and protocols (HTTP, FTP, streaming, MIME type, etc.) — Adds the ability to block 
certain types of content transported on certain types of protocols. 

□ Identity (user, group, network) — Customize policy based on who the users are regardless of 
location. 

□ Network conditions — Customize based on real-time conditions. 

Content and Virus Scanning 

When integrated with a supported Internet Content Adaptation Protocol (ICAP) server such as the 
Blue Coat Proxy/! I 7 appliance. Blue Coat provides content scanning and filtering. ICAP is an evolving 
protocol that allows an enterprise to dynamically scan and change Web content. Content scanning 
includes actions like sending a given request for content to an ICAP server for virus scanning or 
malicious mobile code detection. 

To eliminate threats to the network and to maintain caching performance, the ProxySG sends objects 
to the integrated ICAP server for evaluation and saves the scanned objects in its object store. With 
subsequent content requests, the ProxySG serves the scanned object rather than rescanning the same 
object for each request. 
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Figure 1-2: Content and Virus Scanning 

The ProxySG blocks viruses from Web content behind and in front of the firewall. Blue Coat 
architecture is optimized to handle Web requests and responses that require scanning for potentially 
malicious mobile code and viruses. The ProxySG uses ICAP to vector responses to supported virus 
scanning servers to deliver unmatched flexibility and performance in scanning Web content. 

Spyware 

Spyware leverages multiple vectors, making silver bullet defenses using coarse-grained controls 
useless and unproductive and impeding critical Web-based business communications. No single 
technique can filter out spyware and adware to defend against the threat. 

Blue Coat combines multiple techniques in a high-performance solution acceptable for Web-based 
business communications. Latency is minimal and the protection layers are comprehensive to stop, 
block, and scan spyware. With Blue Coat, you can: 

□ stop spy wa re installations; 

□ block spy wa re Web sites; 

□ scan for spyware signatures; 

□ detect desktop spyware and target for cleanup. 
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Figure 1-3: Preventing Spyware 



For information on using the ProxySG and ProxyAV together, refer to the Blue Coat Proxy AV 
Configuration and Management Guide. 
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Instant Messaging 

Instant Message (IM) usage in an enterprise environment creates security concerns because, regardless 
of how network security is configured, IM connections can be made from any established protocol, 
such as HTTP or SOCKS, on any open port. Because it is common for coworkers to use IM to 
communicate, especially in remote offices, classified company information can be exposed outside the 
network. Viruses and other malicious code can also be introduced to the network from file sharing 
through IM clients. 

The ProxySG serves as an IM proxy, both in transparent and explicit modes. You can control IM 
actions by allowing or denying IM communications and file sharing based on users (both employee 
identities and IM handles), groups, file types and names, and other triggers. You can also log and 
archive all IM chats. 

Using policy, administrators can quickly deploy sophisticated IM usage policies that integrate with 
existing authentication directories through LDAP, IWA and Radius. 
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Figure 1-4: Controlling Instant Messaging 
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Peer-to-Peer 

The very nature of the Peer-to-Peer (P2P) client architecture is to evade firewalls and general network 
security. Additionally, blocking a P2P client at the firewall has proved to be extremely difficult 
because: 

□ port blocking, as a means to controlling P2P, is very limited. 

□ P2P packets cannot be classified simply by looking at packet headers such as an IP address and 
port number. 

Blue Coat ProxySG Appliances provide a powerful platform for immediate and dynamic P2P control. 

Integrated Reverse Proxy 

ProxySG Appliances are easily configured for reverse proxy mode, providing optimized Web server 
acceleration and featuring a high RAM-to-disk ratio and a built-in Secure Sockets Layer (SSL) 
encryption/ decryption processor. This processor can manage 10 to 40 times more secure sessions than 
a standard Web server, allowing the appliances to accelerate the delivery of both public (HTTP) and 
private (HTTPS) content. The product is packaged in a compact 1U form factor (ProxySG 400 and 
ProxySG 800 models) a major advantage in space-constrained data centers, or a 4U form factor 
(ProxySG 8000) that allows for modular expansion of network interface cards, SSL cards, processors, 
and RAM. 
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The ProxySG system software is easily tuned for the workload of high traffic Web sites. This 
environment is characterized by a finite amount of site content accessed by many remote users, often 
resulting in flash crowds. The ProxySG Appliances allow efficient scaling of Web farms to address 
flash or peak periods of traffic, and includes advanced features such as protection against 
Denial-of-Service attacks and dynamic content acceleration. 

Bandwidth Management 

Bandwidth management allows you to classify, control, and, if required, limit the amount of 
bandwidth used by different classes of network traffic flowing into or out of the ProxySG. Network 
resource sharing (or link sharing) is accomplished using a bandwidth-management hierarchy where 
multiple traffic classes share available bandwidth in a controlled manner. 

You can also create policies to constrain who can use certain media types, and how much of it. For 
example, you can allow your executives to view high-bandwidth streaming media, but only allow the 
accounting group to view streams up to 56k on corporate sites. 

With Blue Coat, you can limit access based on user, group, network address, and the time of day. You 
can also prevent all access to the Internet except for a group of users who need access to do their jobs, 
effectively freeing bandwidth for mission-critical needs. 



New Features in this Release 

Blue Coat has long been the leader in proxy appliances. For SGOS 4.2, Blue Coat built upon this 
leadership by adding: 

□ Support for Kerberos and Integrated Windows Authentication (IWA), replacing NTLM as an 
authentication realm where appropriate 

□ SSL Proxy 

□ Certification Revocation List support 

□ Support for RADIUS servers that use challenge/ response as part of the authentication process as 
well as support for RADIUS groups and the ability to fine-tune RADIUS realms with a number of 
new attributes 

□ New authentication forms to support RSA SecurlD and Secure Computer Safe Word 

□ New policy to support new SGOS 4.2 features 

For information on each of these features, continue with the following sections. 

Integrated Windows Authentication (IWA) and Kerberos Support 

Windows 2000 and later provides an authentication mechanism based on Kerberos. Users can 
automatically choose between Kerberos and NTLM as appropriate. All existing features of the Blue 
Coat implementation of the NTLM realm are available, but IWA realms can participate in Kerberos 
authentication as well as the automatic choosing of Kerberos or NTLM. 

Blue Coat has renamed the NTLM authentication realm to be IWA. All original functionality remains, 
and Kerberos is enabled by default. 
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Note: BCAAA installation changes with the addition of Kerberos support. For more information 

on installing BCAAA in a Kerberos environment, see Appendix A: "Using the 
Authentication/ Authorization Agent" on page 1021. 



SSL Proxy 

The SSL proxy allows you to intercept HTTPS traffic so that security measures like virus scanning and 
URL filtering can be applied to HTTPS content. Additionally, the SSL proxy allows you to validate 
server certificates presented by various HTTPS sites at the gateway and offers rich information about 
the HTTPS traffic in the access log. 

For information on understanding and configuring an SSL proxy, see "Configuring an SSL Proxy" on 
page 235. 

Certificate Revocation List 

Certificate Revocation Lists (CRLs) can be used in multiple situations: 

□ SSL proxy when intercepting or tunneling; Certificate revocation lists are incorporated during the 
certificate verification process 

□ HTTP reverse proxy 

□ For ProxySG-originated HTTPS downloads (secure image download, content filter database 
download, and the like) 

For more information on using CRLs, see "Using Certificate Revocation Lists" on page 286x. 

RADIUS Realms and Authentication Form Realms 

The ProxySG supports RADIUS servers that use challenge /response as part of the authentication 
process. Safe Word asynchronous tokens use challenge/response to provide authentication. SecurlD 
tokens use challenge/response to initialize or change PINs. 

To support challenge/ response authentication, two new authentication forms — new_pin_form and 
query_form — have been added to the authentication forms realm. For more information on these two 
new authentication forms, see "Section M: Forms-Based Authentication" on page 473. 



Note: For this release, HTTP is the only supported protocol. 



In addition, you can create RADIUS groups and otherwise fine-tune RADIUS realms through the 
attribute . <name> and has_attribute . <name> CPL conditions and source objects in VPM. 

For more information on RADIUS realms, see "Section E: RADIUS Realm Authentication and 
Authorization" on page 390. 
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New Policy 

New policy gestures — conditions, properties, and actions — have been added to support the SSL proxy, 
CRL, the new authentication forms, as well as new a new Referer header and HTTP content regex 
gestures. For information on using new policy gestures, refer to the Blue Coat ProxySG Content Policy 
Language Guide. 

Protocols Supported 

Blue Coat ProxySGs are multi-protocol. For administrative purposes, you can connect to the Blue Coat 
ProxySG Appliances through the: 

□ HTTPS-Console: This is the default protocol used by the Management Console. It is configured 
and enabled by default. 

□ SSH-Console: This is the default protocol for connecting to the ProxySG through the CLI. It is 
configured and enabled by default. 

If you prefer and are in a secure environment, you can use the HTTP-Console or Telnet-Console for 
administrative access to the system. 



Note: HTTP-Console and Telnet-Console are security risks. They should not be used for 

administrative access in insecure situations. 



Supported Browsers 

The ProxySG Management Console supports Microsoft® Internet Explorer 6, Netscape® 
Communicator 7.2 or 8.x, and Firefox 1.x. 

The Management Console uses the Java Runtime Environment. Because of security concerns, you 
should use JRE 1.5.0 (also called J2SE 5.0) if you plan to access external Internet sites. 

Upgrade and Upgrade Behavior 

For information on doing upgrades or downgrades, or for restoring default system settings, refer to 
the Blue Coat SGOS 4.x Upgrade Guide. 

Where to Go From Here 

The following sections describe the top-level tasks you need to carry out to customize the ProxySG to 
your environment. The tasks are shown in the order of a typical deployment: 



Placing the ProxySG in a Network 

To install a ProxySG into a network, the network must be set up to present the ProxySG with traffic to 
control. 

□ Explicit Proxy: All the ProxySG needs is IP address connectivity to the network; browsers must be 
configured to point to the ProxySG through a PAC file. 
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□ Transparent Proxy: The majority of networks use transparent proxy Transparent proxying occurs 
when the ProxySG receives traffic destined for Origin Content Servers (OCS) and terminates the 
traffic, then initiates the same request to the OCS. 

• Bridging: With this configuration, you do not have to make router or L4 switch configuration 
changes. The ProxySG is placed inline on a segment of the network where all outgoing traffic 
flows; one Ethernet interface is connected to the internal network, the other Ethernet interface 
is connected to the Internet. The ProxySG terminates all traffic on the service ports in which 
the proxy has been configured and sends the request to the outside OCS. All other traffic is 
bridged between the two Ethernet interfaces. 

Note that this configuration, without using policy controls, can lead to an open proxy. An open 
proxy results when traffic is allowed on the outside (Internet) interface because users are 
accessing internal Web servers behind the proxy. 

• WCCP: If the site has Cisco routers, WCCP can be used to direct certain TCP/IP connections 
to the ProxySG. TCP/IP ports to forward to the ProxySG are communicated between ProxySG 
appliances and the Cisco routers. Typically, this is enforced on the outgoing interface on the 
Cisco router. 

• L4 switching: Similar to WCCP, the L4 switch is configured to forward traffic for specific 
TCP/IP ports to the attached ProxySG. 

Initial Setup 

The ProxySG must be initially configured before it operates on a network. This can be done through 
the front panel (if applicable) or the serial console. The initial setup sets not only the IP address, but 
enable and console passwords. Once completed, the ProxySG can be managed through the serial 
console, SSH, or HTTPS at port 8082. Information on setting up the ProxySG is in the Quick Start 
Guide and Installation Guide for your platform. 

Simple Policy 

The default policy on new ProxySG appliances is to deny everything. To test initial setup, you can 
create a policy of ALLOW, along with changing access logging to log to the default logs. If the 
ProxySG is correctly set up, Web browsers can surf the Internet and all transactions are logged. Once 
the ProxySG setup is verified, the policy should again be set to DENY, unless otherwise required. 

If the policy is set to allow everything and a bridged configuration is used, clients can send a 
connection request for any port, including e-mail, using the proxy to send spam. This is called an open 
proxy and usually results in performance slowdowns (among other things). 

To prevent the ProxySG from becoming an open proxy in a bridged configuration if you must use an 
ALLOW configuration, add the following policy to the end of the local policy: 

define subnet Trusted_Clients 
10 . 0 . 0 . 0/8 
end subnet 

define subnet Trusted_Servers 
216 . 52 . 23 . 0/24 
end subnet 



37 



Blue Coat Proxy SG Configuration and Management Guide 



< Proxy > 

client . address = Trusted_Clients OK ; Policy below applies 
proxy . address = Trusted_Servers OK ; Policy below applies 
FORCE_DENY ; Force a denial for everything else 
< Proxy > 

; Add other allow or deny rules here 
; Example: Allow all traffic not denied above 
ALLOW 

Implementing Policies 

Once the basic system is set up, you need to decide which controls — policies — to put in place. 
Typically, the following are configured on the system: 

□ Proxy caching (HTTP, FTP, Streaming) 

□ Authentication/ single sign-on 

□ Access control policy 

□ Content filtering 

□ Web anti-virus 

Implementing policies is a two-step process: 

□ Configure the feature; for example, choose Blue Coat Web Filter (BCWF) or another content 
filtering vendor, enable it, and schedule downloads of the database. 

□ Create policy through the graphical Visual Policy Manager (VPM) or through the Content Policy 
Language (CPL). 

Managing the ProxySG 

Once the configuration and policy on the ProxySG are set, you should know how to evaluate the 
current operating state. This can include reviewing event log messages, utilizing SNMP, or diagnostics 
such as CPU utilization. 

□ Archive a configuration file: "Archiving a Configuration” on page 83 

□ Upgrade the system: "Upgrading the ProxySG" on page 945 

□ Set up event logging: "Event Logging and Notification" on page 951 

□ Configure SNMP: "Configuring SNMP" on page 957 

□ Understand Diagnostics: Appendix E: "Diagnostics" on page 1121 

Managing the ProxyAV 

The ProxySG with ProxyAV™ integration is a high-performance Web anti-virus (AV) solution. For 
most enterprises, Web applications and traffic are mission-critical, representing 90% of the total 
Internet traffic. 

By deploying the ProxySG /ProxyAV solution, you gain performance and scalability (up to 250+ Mbps 
HTTP throughput), along with Web content control. 
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For information on managing the ProxyAV, refer to the Blue Coat Proxy AV Configuration and 
Management Guide. 

Troubleshooting 

Use the access logs, event logs, and packet captures to check connections and view traffic passing 
through the ProxySG. Use policy tracing to troubleshoot policy. Note that policy tracing is global; that 
is, it records every policy-related event in every layer. Turning on policy tracing of any kind is 
expensive in terms of system resource usage and slows down the ProxySG's ability to handle traffic. 

□ Policy tracing: For information on using policy tracing, see "Policy Tracing" on page 556. 

□ Access Logs: For information on configuring and using access logs, see Chapter 20: "Access 
Logging" on page 887. 

□ Event logs: For information on using event logs, see "Event Logging and Notification" on 
page 951. 

□ Packet capture: For information on using the PCAP utility, see "Packet Capturing (the PCAP 
Utility)" on page 1130. 

Task Tables 

The tables below refer to the sections in the manuals that describe the top-level tasks to customize the 
ProxySG to your environment. The tables are listed in alphabetical order (for example, access logging, 
authentication, bridging, caching, and so on). 

Table 1.1: Access Logging 



Task 


Reference 


Configure access logging with 

• Blue Coat Reporter 

• SurfControl Reporter 

• Websense Reporter 


• Blue Coat Reporter: Chapter 3, "Creating the First 
Profile," Blue Coat Reporter Configuration and Management 
Guide 

• SurfControl Reporter: "Using SurfControl Reporter with 
SGOS 4.x” on page 823 

• Websense Reporter: "Configuring Websense" on page 824 



Table 1.2: Anti-Virus 



Task 


Reference 


Block Web viruses using ProxyAV 


"Section A: ICAP" on page 512; Blue Coat ProxyAV 
Configuration and Management Guide 


Set up anti-virus filtering 


Blue Coat ProxyAV Configuration and Management Guide 
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Table 1 .3: Authentication 



Task 


Reference 


Achieve single sign-on with IWA (formerly 
NTLM) 


"Section A: IWA Realm Authentication and Authorization" 
on page 341 


Select the right authentication mode 


"Understanding Authentication Modes" on page 323 


Install the Blue Coat 

authentication/ authorization agent to work 
with IWA (formerly NTLM) 


Appendix A: "Using the Authentication/Authorization 
Agent" on page 1021 


Configure authentication to work with an 
existing authentication service 


Chapter 9: "Using Authentication Services" on page 339 


Set up authentication schemes and use them in 
policy 


Chapter 8: "Security and Authentication" on page 309 



Table 1.4: Bridging 



Task 


Reference 


Configure bridging (hardware or software) 


"Section D: Software and Hardware Bridges" on page 91 


Allow those from outside a bridged deployment 
to get to internal servers 


"Defining Static Routes" on page 100 



Table 1.5: Caching 



Task 


Reference 


Disable caching 


"Configuring Refresh Bandwidth for the HTTP Proxy" on 
page 195 



Table 1 .6: HTTP 



Task 


Reference 


Redirect HTTP with WCCP 


"Standard HTTP Redirection" on page 1107 



Table 1 .7: HTTPS 



Task 


Reference 


Create a transparent HTTPS service 


"Managing the HTTPS Reverse Proxy" on page 169 
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Table 1.8: Instant Messaging 



Task 


Reference 


Allow, block, and control the supported Instant 
Messaging clients 


Chapter 17: "Instant Messaging" on page 769 



Table 1.9: Management 



Task 


Reference 


Get the Management Console to work 


Chapter 3: "Accessing the ProxySG" on page 59 


Manage the System: 

• License the system 

• Back up the configuration 

• View statistics 
® Resources 
® Efficiency 

• SNMP monitoring 


• Chapter 2: "Licensing" on page 47 

• "Archiving a Configuration" on page 83 

• Chapter 22: "Statistics" on page 973 

• "Resources Statistics" on page 1001 

• "Efficiency Statistics" on page 1004 

• "Configuring SNMP" on page 957 



Table 1.10: Policy 



Task 


Reference 


Set up authentication schemes and use them in 
policy 


Chapter 8: "Security and Authentication" on page 309 


Limit network access and configuring 
compliance pages 


"Section B: Controlling Access to the Internet and Intranet" 
on page 323 


Block unwanted content 


"How to Apply Policy to Categorized URLs" on page 833 


Change policy default 


"Transaction Settings: Deny and Allow" on page 555 


Write policy using the Visual Policy Manager 
(VPM) 


"Section E: Tutorials" on page 682 


Write policy using the Content Policy Language 
(CPL) 


Blue Coat ProxySG Content Policy Language Guide 



Table 1.11: Proxies 



Task 


Reference 


Determine the best type of proxy for the 
environment 


Chapter 6: "Configuring Proxies" on page 181 


Set up HTTPS Reverse Proxy 


"Section D: Configuring HTTP or HTTPS Origination to the 
Origin Content Server" on page 297 
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Table 1.11: Proxies (Continued) 



Get traffic to the proxy 



Chapter 6: "Configuring Proxies" on page 181 



Table 1.12: Reporter, Blue Coat 



Task 


Reference 


Make Blue Coat Reporter work with access 
logging 


"Section G: Configuring the Upload Client" on page 909; 
Blue Coat Reporter: Chapter 3, "Creating the First Profile," 
Blue Coat Reporter Configuration and Management Guide 


Use Scheduler to set up report generation 


Chapter 3, "Using Scheduler," in the Blue Coat Reporter 
Configuration and Management Guide 


Generate specific reports for specific people 


Blue Coat Reporter Configuration and Management Guide 



Table 1.13: Reporter, SurfControl 



Task 


Reference 


Configure SurfControl Reporter 


"Using SurfControl Reporter with SGOS 4.x" on page 823 



Table 1.14: Reporter, Websense 



Task 


Reference 


Configure Websense Reporter 


"Configuring Websense" on page 824 



Table 1.15: Services 



Task 


Reference 


Create a port service 


"Section B: Creating and Editing Services" on page 160 



Table 1.16: Streaming 



Task 


Reference 


Control streaming protocols 


Chapter 16: "Streaming Media" on page 729 



Table 1.17: WCCP 



Task 


Reference 


Configure WCCP for multiple ports 


"Creating a Configuration File" on page 1102 


Redirect HTTP with WCCP 


"Standard HTTP Redirection" on page 1107 
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Table 1.17: WCCP 



Task 


Reference 


Configure the home-router IP 


"Creating a Configuration File" on page 1102 


Configure multiple home-routers 

Configure a multicast address as the proxy's 
home router 


"Creating a Configuration File" on page 1102 

"Configuring a WCCP Version 2 Service on the Router" on 
page 1090 



About the Document Organization 

This document is organized for easy reference, and is divided into the following sections and chapters: 



Table 1.18: Document Organization 



Chapter Title 


Description 


Chapter 1 - Introducing the ProxySG 


This chapter discusses the ProxySG Security Solution and 
new features and enhancements in SGOS 3.x. It also covers 
document conventions. 


Chapter 2 - Licensing 


Several features must be licensed to be used beyond the 
evaluation trial date. This chapter describes which features 
require licenses and how to download licenses. 


Chapter 3 - Accessing the ProxySG 


This chapter explains how to log in to the ProxySG CLI and 
Web-based Management Console; how to change the 
administrator username, password, privileged-mode 
password; and how to make a secure connection using SSH 
and HTTPS. 


Chapter 4 - Configuring the System 


Instructions on setting the ProxySG name and system time, 
configuring the network adapter, load balancing, and FTP 
port services, and specifying DNS servers. This chapter also 
describes how to track client IP addresses using server-side 
transparency or virtual IP addresses. 


Chapter 5 - Managing Port Services 


This chapter describes port services configurable on the 
ProxySG, including several kinds of Management Consoles, 
such as HTTPS, HTTP, SSH, and Telnet Consoles, and 
application proxies such as Instant Messenger (IM), SOCKS, 
FTP, MMS, and RTSP, HTTP and HTTPS. 


Chapter 6 - Configuring Proxies 


Explicit and Transparent proxies are discussed in this 
chapter, as well as the recommended types of proxy. 


Chapter 7 - Using Secure Services 


HTTPS termination, including SSL, Certificates, keyrings, 
and keypairs are discussed in this chapter. 


Chapter 8 - Security and Authentication 


Enabling and maintaining security on the ProxySG is 
discussed in this chapter. 
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Table 1.18: Document Organization (Continued) 



Chapter Title 


Description 


Chapter 9 - Using Authentication Services 


Blue Coat supports six kinds of authentication, discussed 
here: LDAP, IWA, RADIUS, Local (formerly UNIX), 
Certificate (which allows you to authenticate using 
certificates), and Sequence (which allows you to 
authenticate using multiple authentication servers). 


Chapter 10 - Bandwidth Management 


Managing the amount of bandwidth used by different 
classes of network traffic is discussed in this chapter. 


Chapter 11 - External Services 


ICAP and Websense off -box are described in this chapter. 


Chapter 12 - Health Checks 


The health of services, such as SOCKS, ICAP, and 
forwarding services, is discussed in this chapter. 


Chapter 13 - Managing Policy Files 


Four policy files are used to manage policy: Central, Local, 
Visual Policy Manager, and Forwarding. This chapter 
discusses how to manage them. 


Chapter 14 - The Visual Policy Manager 


This chapter contains a reference guide and several tutorials 
for using the Visual Policy Manager. 


Chapter 15 - Advanced Policy 


This chapter discusses using features such as pop-up ad 
blocking, managing active content, and creating exceptions. 


Chapter 16 - Streaming Media 


This chapter discusses streaming, including the new RTSP 
proxy. 


Chapter 17 - Instant Messaging 


How to configure and use the ProxySG's instant messaging 
capabilities is discussed in this chapter. 


Chapter 18 - Content Filtering 


This chapter discusses how to configure and use the 
ProxySG's content filtering capabilities, as well as 
configuring and using content filtering vendors to work 
with the ProxySG. 


Chapter 19- Configuring the Upstream 
Networking Environment 


This chapter discusses how to control upstream interaction 
with the ProxySG. 


Chapter 20 - Access Logging 


Log formats, upload clients, upload schedules, and 
protocols are discussed in this chapter. 


Chapter 21 - Maintaining the ProxySG 


This chapter discusses upgrading the system and 
configuring event logs, SMNP, STMP, heartbeats, and core 
images. 


Chapter 22 - Statistics 


This chapter discusses viewing various kinds of 

statistics — system usage, efficiency, resources, and logs of all 

kinds. 


Appendix A - Using the Authentication/ 
Authorization Agent 


The ProxySG BCAAA agent is discussed in this appendix. 


Appendix B - Access Log Formats 


ELFF, SQUID, NCSA/Common, and custom logs are 
discussed in this appendix. 
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Table 1.18: Document Organization (Continued) 



Chapter Title 


Description 


Appendix C - Using WCCP 


Configuring and using a WCCP router with the ProxySG is 
discussed in this appendix. 


Appendix D - RIP Commands 


Commands supported for the Routing Information Protocol 
(RIP) configuration text file are discussed in the appendix. 


Appendix E - Diagnostics 


Determining and resolving ProxySG problems are discussed 
in this appendix. 


Appendix F - Using Blue Coat Director to 
Manage Multiple ProxySG Appliances 


Discusses how Blue Coat Director works with multiple 
ProxySG Appliances. 



Note: The Blue Coat ProxySG Configuration and Management Guide and the online help contain the 

same information but are not identical. For the latest information, refer to the Blue Coat 
ProxySG Configuration and Management Guide. 



Related Blue Coat Documentation 



□ Blue Coat 6000 and 7000 Installation Guide 
n Blue Coat 200 Series Installation Guide 

□ Blue Coat 400 Series Installation Guide 

□ Blue Coat ProxySG 800 Series Installation Guide 
n Blue Coat ProxySG 8000 Series Installation Guide 
n Blue Coat ProxySG Content Policy Language Guide 

□ Blue Coat ProxySG Command Line Reference 



Document Conventions 

The following section lists the typographical and Command Line Interface (CLI) syntax conventions 
used in this manual. 

Table 1.19: Typographic Conventions 

Conventions Definition 

Italics The first use of a new or Blue Coat-proprietary term. 

Courier font Command line text that appears on your administrator 

workstation. 

Couri er Italics A command line variable that is to be substituted with a literal 

name or value pertaining to the appropriate facet of your network 
system. 
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Table 1.19: 
Courier 

{ } 

[ ] 



Typographic Conventions 

Boldface A ProxySG literal to be entered as shown. 

One of the parameters enclosed within the braces must be 
supplied 

An optional parameter or parameters. 

Either the parameter before or after the pipe character can or must 
be selected, but not both. 
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This chapter describes the ProxySG licensing behavior. 

About Licensing 

SGOS 4.x features a global licensing system for the ProxySG. License key files are issued on a 
per-appliance basis. One license key file includes all of the component licenses for whichever ProxySG 
features you have elected to use. 



Note: When your ProxySG order was completed, you received an e-mail that contains serial 

numbers for licensable components. Those numbers are required for the procedures in 
this chapter. 



Licensable Components 

There are three types of licensable components: 

□ Required — The SGOS 4 Base; these features are required on the ProxySG. 

□ Included — Additional SGOS 4.x features, which are provided by Blue Coat. 

D Optional — Any additional (purchased) features. 

When the license key file is created, it consists of all three components. The following table lists the 
ProxySG licensable components, categorized by type. 

Table 2.1: Licensable Components 



Type 


Component 


Description 


Required 


SGOS 4 Base 


The ProxySG operating system, plus base features: HTTP, FTP, TCP-Tunnel, 
SOCKS, and DNS proxy. 


Included 


3rd Party Onbox 
Content Filtering 


Allows use with third-party vendor databases: Intersafe, Optenet, Proventia, 
SmartFilter, SurfControl, Websense, and Webwasher. 


Included 


Websense Offbox 
Content Filtering 


For Websense off-box support only. 


Included 


ICAP Services 


External virus and content scanning with ICAP servers. 


Included 


Bandwidth 

Management 


Allows you to classify, control, and, if required, limit the amount of 
bandwidth used by different classes of network traffic flowing into or out of 
the ProxySG. 


Included 


Windows Media 
Standard 


MMS proxy; no caching or splitting; content pass-through. Full policy control 
over MMS. 
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Table 2.1 : Licensable Components (Continued) 



Type 


Component 


Description 


Included 


Real Media 
Standard 


RTSP proxy; no caching or splitting; content pass-through. Full policy control 
over RTSP. 


Included 


Apple QuickTime 
Basic 


RTSP proxy; no caching or splitting; content pass-through. Full policy control 
over RTSP. 


Included 


Netegrity 

SiteMinder 


Allows realm initialization and user authentication to SiteMinder servers. 


Included 


Oracle COREid 


Allows realm initialization and user authentication to COREid servers. 


Included 


Peer-to-Peer 


Allows you to recognize and manage peer-to-peer P2P activity relating to P2P 
file sharing applications. 


Included 


Compression 


Allows reduction to file sizes without losing any data. 


Optional 


SSL Proxy 
(Native SSL 
Proxy and 
Reverse HTTPs 
Proxy, also called 
SSL Termination) 


Native SSL proxy and Reverse HTTPS Proxy (SSL termination) on the 
ProxySG. Includes an SSL accelerator card to be installed on the appliance. 
Upon upgrading to SGOS 4.2, the license description for an existing SSL 
license changes to "SSL Proxy" instead of "SSL Termination." This is simply a 
description change. SSL termination and SSL Proxy functionality are available 
(when licensed) on SGOS 4.2. 


Optional 


IM 


• AOL Instant Messaging: AIM proxy with policy support for AOL Instant 
Messenger. 

• MSN Instant Messaging: MSN proxy with policy support for MSN Instant 
Messenger. 

• Yahoo Instant Messaging: Yahoo proxy with policy support for Yahoo 
Instant Messenger. 


Optional 


Windows Media 
Premium 


• MMS proxy; content caching and splitting. 

• Pull policy control over MMS. 

• When the maximum concurrent streams is reached, all further streams are 
denied and the client receives a message. 


Optional 


Real Media 
Premium 


• RTSP proxy; content caching and splitting. 

• Pull policy control over RTSP. 

• When the maximum concurrent streams is reached, all further streams are 
denied and the client receives a message. 



About the Trial Period 

Blue Coat provides a trial period. The initial system boot-up triggers the 60-day trial period, during 
which you can evaluate the ProxySG functionality. For the first 60 days, all licensable components are 
active and available to use. Furthermore, when a license is installed during the trial period (or while 
using a demo license), components that are not part of that license remain available and active during 
the trial period. 
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Note: The ProxySG Licensing feature has slight changes from SGOS 3.x. The Blue Coat SGOS 4.x 

Upgrade Guide (in Chapter 2) describes licensing behavior concerning an upgrade to SGOS 
4.x from SGOS 3.x. 



Each time you navigate to the Management Console home page or click the Maintenance>Licensing tab, 
a pop-up dialog appears warning you that the trial period expires in so many days (a text message is 
displayed on a Telnet, SSH, or serial console). If you require more time to explore the ProxySG 
features, a demo license is available; refer to your reseller or contact Blue Coat Sales. 

The trial period streaming and IM licenses are no-count licenses — unlimited streams and IM clients 
are accessible. 

Upon installing licenses after or during the trial period, the Base SGOS, Instant Messaging (IM), 
Windows Media basic, and Real Media premium licenses are also unlimited, but Windows Media 
premium and IM licenses impose user limits established by each license type. 



Note: If you invoke the restore-defaults command after you have installed licenses, and the 

serial number of your system is configurable (older boxes only), the licenses fail to install 
and you return to the trial period (if any time is left). 



About License Expiration 

At the end of the trial or demo period or, subsequently, when any normally licensed component 
expires, components that have not been licensed do not process requests. A license expiration 
notification message is logged in the Event Log (see "Viewing the Event Log" on page 1009 for 
information). 

If a license expires, users might not receive notification, depending upon the application they are 
using. Notifications do occur for the following: 

□ HTTP (Web browsers) — An HTML page is displayed stating the ProxySG license has expired. 

□ SSL — An exception page appears when an HTTPS connection is attempted. 

□ Instant Messaging clients — Users do not receive a message that the ProxySG license has expired. 
Any IM activity is denied, and to the user it appears that the logon connection has failed. 

□ FTP clients — If the FTP clients supports it, a message is displayed stating the ProxySG license has 
expired. 

□ Streaming media clients — If the Windows Media Player, RealPlayer, or QuickTime player version 
supports it, a message is displayed stating the ProxySG license has expired. 

You can still perform ProxySG configuration tasks through the Management Console, CLI, SSH 
console, serial console, or Telnet connection. Although the component becomes disabled, feature 
configurations are not altered. Also, policy restrictions remain independent of component availability. 
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Obtaining a WebPower Account 

Before you can generate the license key file, you must have a Blue Coat WebPower user account and 
register the ProxySG. 

If you do not have a WebPower account or forgot your account information, perform the following 
procedure. 

To Obtain a WebPower Account 

1. Select Maintenance>Licensing>lnstall. 

2. In the License Administration field, click Register/Manage. The License Configuration and 
Management Web page appears (ignore the dialog at this time). 

3. Perform one of the following: 

• To obtain a new account, click the link for Need a WebPower User ID. Enter the information as 
prompted. 

• To obtain your current information for an existing information, click the link for Forgot your 
password. 

Registering the Hardware 

This section describes how to enter the appliance serial number and register the appliance with Blue 
Coat. 

System Serial Number Prerequisite 

Each ProxySG serial number is the appliance identifier used to assign a license key file. The ProxySG 
contains an EEPROM with the serial number encoded. The ProxySG recognizes the serial number 
upon system boot-up. 

The serial number is visible by navigating to Configuration>General>ldentification. 

The License Warning Dialog 

When you first access the ProxySG Management Console, or when you select 
Maintenance>Licensing>lnstall, a License Warning dialog appears. 
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Register New Hardware: 

To register and configure a new appliance, enter the model and serial number below. 

H/W Serial I 

Number: ' 

H.'W Model | Ple ase S e | eC t Mod e l M arne ^1 

Number: 1 — 1 

Register New Hardware 



Questions or Comments? Send an email to: supportservices@bluecoat.com 

Figure 2-1 : License Warning dialog: Hardware not registered 

You cannot install a license key until the hardware has been registered. The License Warning field 
indicates this status. 

If you know the hardware has been manually registered, select Hardware has been manually registered 
and click Close. The system searches for the last instance and value of hardware registration. Proceed 
to "Installing a License Key File” on page 51. 

Registering the ProxySG 

This section describes how to register the ProxySG. 

To Register the Hardware 

1. If the License Warning dialog is not displayed, select Maintenance>Licensing. The License Warning 
dialog appears. 

2. Select Register hardware with Blue Coat automatically. 

3. Enter your WebPower username and password. 

4. Click Proceed. The Registration Status field displays relative information. 

The ProxySG connects to the Blue Coat License Self-Service page. The next step is to obtain and 
install the license key file that allows access to the ProxySG features you require. 

Installing a License Key File 

This section describes how to register the ProxySG with Blue Coat and install the license key file. 

Creating a License Key File 

The License Self-Service Web page allows you to create a license key file. 
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Change Hardware Record 



License Self-Service 
You are currently reviewing the software options associated with: 



Hardware Model: 
Hardware Serial Number: 



400-0, 2x1 0/1 OOBase-T 
1003020286 



Valued Customer: IT Manager 

Organization: Blue Coat Systems Inc. 



Currant 

1003020286 - 400-0, 2x10/100Base-T 

the following software options are currently linked to this product. To modify this configuration, select the appropriate tab below and follow the 
instructions. 

Software S/N Description Expires Limit 



Oust Info 

Links 

Go to Web Power 
Contact Technical Support 

Contact Support Services for configuration assistance. 

Get Ucense For Manual Installation. (Opens in a new window.) 
Detailed instructions on downloading your lioense are available from 
the appliance kibnagement Console. To view these, navigate to 
'tubintenance/Ucensing" and click the "Help" button at the bottom of 

Update License Key to support additional features in the latest 
releases. Please see Release Notes for more information. 



Add 

Add a New Software Option to this appliance 

To link a software option that is not listed above, record the software serial number(s) below and click 'Apply/ 



Figure 2-2: The License Self-Service Web page 

Upon purchasing the ProxySG from Blue Coat or a reseller, you received an e-mail that contains 
license serial numbers. These serial numbers are required to create the license key file. 



To Create a License Key File 

1. In the first field under Add a new software solution to this appliance, enter the serial number for the 
SGOS 4.x base license. 

2. In the subsequent fields, enter the serial numbers for any optional licenses you obtained (for 
example. Compression and IM). 

Add a New Software Option to this appliance 

To link a software option that is not listed above, record the software serial numbers J below and click 'Apply'. 

| 1 2345-67890 
|ABCDE-FGHIJ| 



Apply] 

Figure 2-3: Entering license serial numbers 

3. Click Apply. 

A license key file, which contains either just the base license or the base combined with optional 
licenses, is generated and is ready to be downloaded and installed. 



Downloading the License Key File 

Downloading the license key file is accomplished by using the automatic installation feature or by 
receiving the key through e-mail and manually installing it from a Web server or a local file. 
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Automatic License Installation 

If the ProxySG has Internet access, you can use the automatic license installation feature to retrieve 
and install the license from Blue Coat. 

To Automatically Obtain and Install the License from the Management Console 

1. Select Maintenance>Licensing>lnstall. 

2. In the License Key Automatic Installation field, click Retrieve. The Request License Key dialog appears. 




Figure 2-4: Requesting a License 

3. Enter your Blue Coat WebPower user ID and password. 

4. Click Send Request. 

The ProxySG fetches the license associated with the serial number that is displayed. 

5. The Installation Status field displays relevant information. When installation is complete, click 
Results; examine the results and click OK; click Close. The ProxySG is now licensed. 

Manual License Installation 

If the ProxySG does not have Internet access. Blue Coat can send you the license in an e-mail. The file 
can then be installed from a Web server or a local directory. 

To Manually Obtain and Install the License 

1. Select Maintenance>Licensing>lnstall. 

2. Click Register/Manage. A new window opens to the Blue Coat ProxySG Registration page. This 
Web page provides instructions for requesting that the license (associated to the ProxySG by the 
serial number) be sent through e-mail. 

3. When the e-mail arrives, save the attached license file on a Web server or to a local file. 
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4. In the License Key Manual Installation field, select one of the following from the drop-down list and 
click Install: 



Note: A message is written to the event log when you install a list through the ProxySG. 



Remote URL — If the file resides on a Web server. The Install License Key dialog displays. 

Install License Key 



Installation URL: |http:// 




OK | Cancel | Results | 

Figure 2-5: Installing a License from a Web Server 

Enter the URL path and click Install. The Installation Status field displays relevant information. 
When installation is complete, click Results; examine the results, close the window, and click 
OK. Click Apply. 

• Local File — If the file resides in a local directory. The Upload and Install File window opens. 



Upload and Install File 



Upload and Install the License Key 

1. Paste the file path into the box below or choose afile 
by clicking the Browse... button and opening the file 

2. Click Install to upload and install the new file. It can 
take some time for the upload to complete. Your 
browser may be unresponsive during the upload. 

3. Once the installation is completed the results willbe 
displayed in a new page. Close the results page once 
you have finished viewing the results. 



File to upload: 



Browse.. 



Install | Close | 

Figure 2-6: Uploading a License from a Local File 



Enter a path to the license file or click Browse and navigate to the file. Click Install. A results 
window opens. Examine the license installation results; close the window. Click Close. Click Apply. 

The ProxySG license is now installed. All features that you subscribed to are fully operational. 
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Viewing License Information 

You can review the validity and expiration date of any licensed feature. 

To View the License Information through the Management Console 
Select Maintenance>Licensing>View. 



View | Install 

Licensed Components 



Component 


Valid 


Expiration Date 




SG0S4 


yes 


2006-01-03 


/V 


3rd Parly Onbox Content ... 


yes 


2006-01-03 




Websense Offbox Conte... 


yes 


2006-01-03 




ICAP Services 


yes 


2006-01-03 




AOL Instant Messaging 


yes 


2006-01-03 


V 



View Details 



Refresh Data 



r General License Information 



Hardware serial number: (not available) 
T rial expiration date: 2006-01 -03 



T rial Components are enabled 



Q Disable 



Figure 2-7: Viewing License Information 

Each licensable component is listed, along with its validity and its expiration date. 



Note: To view the most current information, click Refresh Data. 



You can also highlight a license component and click View Details. A dialog appears displaying more 
detailed information about that component. For example, a streaming component displays the 
maximum number of streams allowed. 

If the trial period is enabled and you click Maintenance > Licensing > View, the Management Console 
displays a check box to disable the trial components. If the trial period is disabled, the Management 
Console displays a check box to enable the trial components. 

Disabling the Components Running in Trial Mode 

You might decide to not let users access ProxySG features that are currently running in trial mode. 

To Disable Trial Mode Components from the Management Console: 

1. On the View License tab, select Trial Components are enabled: Disable. 

2. Click Apply. 

3. Click Refresh Data. All licenses that are in trial mode switch from Yes to No. Users cannot use these 
features. Furthermore, they do not receive nag dialogs warning of license expiration. 

Also notice that this option text changes to Trial Components are disabled: Enabled. Repeat this process to 
re-enable trial licenses. 
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To Disable Trial Mode Components from the CLI 

At the enable prompt, enter the following command: 

SGOS# licensing disable-trial 

To re-enable: 

SGOS# licensing enable-trial 

Updating a License 

After the initial license installation, you might decide to use another feature that requires a license. For 
example, you currently support Windows Media, but want to add Real Media support. The license 
must be updated to allow this support. 

To Update a License through the Management Console 

1. Select Maintenance>Licensing>lnstall. 

2. Click Register/Manage. 

3. Follow the instructions on the Blue Coat License Self-Service Web page. 

4. If using the automatic license installation feature, click Update; otherwise, manually install the 
license as described in "Manual License Installation" on page 53. 

To Update a License through the CLI 

At the enable prompt, enter the following command: 

SGOS# licensing update-key 

Automatically Updating a License 

The license automatic update feature allows the ProxySG to contact the Blue Coat licensing Web page 
31 days before the license is to expire. If a new license has been purchased and authorized, the license 
is automatically downloaded. The ProxySG continues to contact the Web site up to 30 days after the 
license is set to expire. Outside the above license expiration window, the ProxySG performs this 
connection once every 30 days to check for new license authorizations. This feature is enabled by 
default. 

To Configure the License Auto-Update Feature through the Management Console 

1. Select Maintenance>Licensing>lnstall. 

2. Select Use Auto-Update. 

3. Click Apply. 

To Configure the License Auto-Update Feature through the CLI 

At the (config) prompt, enter the following command: 

SGOS# (config) license-key path url 

SGOS# (config) license-key auto-update {enable | disable} 
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Note: If the automatic license update fails and you receive a Load from Blue Coat error, 

you must log on to your License Management account: 

https : // services . bluecoat . com/ eservice_enu/ licensing/mgr . cgi. Click Update 
License Key. 
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The Blue Coat Systems ProxySG uses the Secure Shell (SSH) and HTTPS protocols to securely access 
the ProxySG CLI and Management Console. Both SSHvl and SSHv2 are enabled by default, and host 
keys have already been created on the ProxySG. 

All data transmitted between the client and the ProxySG using SSH/HTTPS is encrypted. 

During initial configuration, you assigned the ProxySG a username and password and a 
privileged-mode (enabled / configuration) password. These passwords are always stored and 
displayed hashed. 

This chapter discusses: 

□ "Before You Begin: Understanding Modes" 

□ "Accessing the ProxySG" 

O "Accessing the Management Console Home Page" 

□ "Changing the Logon Parameters” 

□ "Configuring the SSH Console" 



Important: This chapter assumes that you have completed the first-time setup of the ProxySG 

using either the front panel or serial console, and that the appliance is running on the 
network. These steps must be completed before accessing the appliance. 



You can manage the ProxySG by logging on to and using one of the following: 

□ An SSH session to access the CLI. 

□ The Management Console graphical interface. 

You can also use a serial console to access the CLI. 



Note: To use a Telnet session, you must use a serial console connection until you have 

configured Telnet for use. (For security reasons Blue Coat does not recommend using 
Telnet). 



Before You Begin: Understanding Modes 

SGOS 4.x supports different levels of command security: 

□ Standard, or unprivileged, mode is read-only. You can see but not change system settings and 
configurations. This is the level you enter when you first access the CLI. 



59 



Blue Coat Proxy SG Configuration and Management Guide 



□ Enabled, or privileged, mode is read-write. You can make immediate but not permanent changes 
to the ProxySG, such as restarting the box. This is the level you enter when you first access the 
Management Console. 

□ Configuration is a mode within the enabled mode. From this level, you can perform permanent 
changes to the ProxySG configuration. 

If you use the Management Console, you are in configuration mode when you are completely logged 
on to the system. 

If you use the CLI, you must enter each level separately: 

Username : admin 
Password : 

SGOS> enable 
Enable Password: 

SGOS# configure terminal 

Enter configuration commands, one per line. End with CTRL-Z. 

SGOS# (config) 

For detailed information about the CLI and the CLI commands, refer to the Blue Coat ProxySG 
Command Line Reference. 



Note: Although most administrator tasks can be performed using either the Management 

Console or the CLI, there is the occasional task that can only be done using one of the two: 
these are specified in the manual. 



Accessing the ProxySG 

You can access the ProxySG through either the CLI or the Management Console. By default, SSHv2 
(CLI) and HTTPS (Management Console) are used to connect to the appliance. 

The SSH and HTTPS ports are configured and enabled. For SSH, you can use either version 1 or 
version 2 (with password or RSA client key authentication). 

Accessing the CLI 

If you use the CLI, you can use SSHv2 to access the ProxySG, but you cannot use SSHvl or Telnet 
without additional configuration. 



Note: Enabling the Telnet-Console introduces a security risk, so it is not recommended. 



To use SSHvl, you must first create an SSHvl host key. For more information on creating SSH host 
keys, see "Configuring the SSH Console" on page 67. 

To log on to the CLI, you must have: 

□ the account name that has been established on the ProxySG 

□ the IP address of the ProxySG 

□ the port number (8082 is the default port number) 
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You must log on from your SSH client. 

Accessing the Management Console 

The Management Console is a graphical Web interface that allows you to manage, configure, monitor, 
and upgrade the ProxySG from any location. 

In the Web browser, enter HTTPS, the ProxySG IP address, and port 8 0 82 (the default management 
port). For example, if the IP address configured during first-time installation is 10.25.36.47, enter the 
URL https : //io .25.36.47: 8082 in the Web browser. 

The Management Console consists of a set of Web pages and Java applets stored on the ProxySG. The 
appliance acts as a Web server on the management port to serve these pages and applets. From the 
ProxySG home page on the appliance, you can access the management applets, statistics applets, and 
documentation. The Management Console is supported with a complete online help facility to assist 
you in defining the various configuration options. 



Note: If, when you access the Management Console home page, you get a "host mismatch" or 

an "invalid certificate" message, you need to recreate the security certificate used by the 
HTTPS-Console. For information on changing the security certificate, see "Managing the 
HTTPS Console (Secure Console)" on page 152. 



Accessing the Management Console Home Page 

When you access the Management Console home page (see "Accessing the Management Console" on 
page 61), you are prompted to log on to the box. 

Logging On 

Each time you access the Management Console, you must log on. 




Figure 3-1: Logon Dialog 

□ The Site is the IP address of the ProxySG to which you are logging on. 
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□ The Realm is a configurable name that can be anything you choose. The ProxySG IP address is the 
default. For more information on configuring the realm name, see "Changing the ProxySG Realm 
Name" on page 66. 

□ The User Name is the name of the account you are using on this ProxySG. The name must already 
exist. It cannot be created here. 

□ The Password is the password for the account you are using. It cannot be changed here. 

You can change the username and password for the console through the Management Console or the 
CLI. See "Changing the Logon Parameters" on page 63. 



Note: All successful and failed logon attempts are logged to the ProxySG event log. 



Logging Out 

Once you have logged on, you do not have to log on again unless you exit the current session or the 
session times out. The session timeout period, with a default of 900 seconds (15 minutes), is 
configurable. 

Thirty seconds before the session times out, a warning dialog displays. Click the Keep Working button 
or the X in the upper-right-corner of the dialog box to keep the session alive. 



Note: The Keep Working button saves your changes to the current applet. You cannot work in 

other applets without logging back on to the ProxySG. 



Inactivity Logout Warning 



Auto-Logout 

You ate now logged out of the Management Console. 

Do you wish to close the console now, or finish working with 
any changes left in the current session? 

Warning: Console wifi close in 12 seconds. 

} Kee^ Working || Close Console | 

Figure 3-2: Automatic Logout Warning 

If you do not click Keep Working or the X in the upper-right-hand corner within the thirty-second 
period, you are logged out. You must log back on to access the Management Console. 

You have logged out. Please close the browser window. 



You need to Ioh in aHarn to use the console 

Figure 3-3: Logout Dialog 

Click the hyperlink to log back on to the ProxySG. 
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Note: If no applet is running when the session times out (you are on the Management Console 

home page), you are logged out without seeing the logout warning dialog. You might not 
be aware that you are logged out until you try to access an applet. You must enter the 
logon information again. 



Changing the Logon Parameters 

You can change the console username and password, the console realm name (which displays when 
you log on to the ProxySG), and the auto-logout timeout (in seconds; the default is 900 seconds.) 

The Management Console requires a valid administrator username and password to have full 
read-write access; you do not need to enter a privileged-mode password as you do when using the 
CLI. A privileged-mode password, however, must already be set. 



Note: To prevent unauthorized access to the ProxySG, only give the console username and 

password to those who administer the ProxySG. 



Changing the Username and Password through the Management Console 

You can change either the username or the password without changing both. 

Changing the Username through the Management Console 

The console account username was assigned during initial setup of the system. You can change the 
username at any time. 

To Change the Username through the Management Console 
1. Select Configuration>Authentication>Console Access>Console Account. 

The Console Account tab displays. 

Console Account Console Access 




Figure 3-4: Console Account Tab 
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Note: Changing the Console Account username or password causes the Management Console 

to refresh and log back on using the new information. Note that each parameter must be 
changed and individually refreshed. You cannot change both parameters at the same 
time. 



2. Enter the username of the administrator or administrator group who is authorized to view and 
revise console properties. 

Only one console account exists on the ProxySG. If you change the console account username, that 
username overwrites the existing console account username. 

The console account username can be changed to anything that is not null and contains no more 
than 64 characters. 

3. Click Apply. 

After clicking Apply, an Unable to Update configuration error is displayed. The username change was 
successfully applied, but the configuration could not be fetched from the ProxySG, as the 
username offered in the fetch request is still the old username. 

4. Refresh the screen. You are then challenged for the new username. 

To Change the Password through the Management Console 

The console password and privileged-mode password were defined during initial configuration of the 
system. The console password can be changed at any time through the Management Console. The 
privileged-mode, or enabled-mode, password can only be changed through the CLI or the serial 
console. 

1. Select Configuration>Authentication>Console Access>Console Account. 

The Console Account tab displays. 

2. Click Change Password. 




Figure 3-5: Setting or Changing a Password 

3. Enter and re-enter the console password that is used to view and edit configuration information. 
The password must be from 1 to 64 characters long. As you enter the new password, it is obscured 
with asterisks. Click OK. 
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Note: This does not change the enabled-mode password. You can only change the 

enabled-mode password through the CLI. 



4. Refresh the screen, which forces the ProxySG to re-evaluate current settings. When challenged, 
enter the new password. 

5. (Optional) Restrict access by creating an access control list or by creating a policy file containing 
<Admin> layer rules. For more information, see "Moderate Security: Restricting Management 
Console Access Through the Console Access Control List (ACL)" on page 315. 

Changing the Username and Password through the CLI 

To Change the Console Account Username or Password, Privileged-Mode Password, and the 
Front-Panel PIN through the CLI 

1. Open a terminal session with the ProxySG and enter the current username and password as 
prompted. 

2. At the command prompt, enter the following command: 

SGOS> enable 

3. Enter the privileged-mode password when prompted. 

4. At the command prompt, enter the following commands (note that usernames and passwords can 
each be from 1 to 64 characters in length, but that passwords need to be in quotes): 

SGOS# configure terminal 

SGOS# (config) security username username 

This command specifies the administrator username. 

SGOS# (config) security password "password" 

-or- 

SGOS# (config) security hashed-password hashed_pas sword 

These commands specify the administrator console password. 

SGOS# (config) security enable-password "password" 

-or- 

SGOS# (config) security hashed-enable-password hashed password 

These commands specify the administrator privileged-mode password. The ProxySG hashes 
the password if you enter it in clear text. 

5. (Optional, for maximum security. Note that these commands are not available if the ProxySG does 
not have a front panel.) At the command prompt, change the ProxySG front panel PIN: 

SGOS# (config) security front-panel-pin pin 

-or- 

SGOS# (config) security hashed- front-panel -pin hashed pin 

6 . (Optional) Restrict access by creating an access control list or by creating a policy file containing 
<Admin> layer rules. For more information, see "Section A: Controlling Access to the ProxySG" on 
page 311. 
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Changing the ProxySG Realm Name 

The realm name displays when you log on to the ProxySG Management Console. The default realm 
name is the connection used to access the ProxySG, usually the IP address of the system. 

To Change the Realm Name through the Management Console 

1. Select Configuration>Authentication>Console Access>Console Account. 

The Console Account tab displays. 

2. Enter a new realm name. 

The new realm name displays the next time you log on to the ProxySG Management Console. 

3. Click Apply. 

To Change the Realm Name through the CLI 

1. At the (config) prompt, enter the following command to change the name from the default. 
SGOS# (config) security management display-realm name 

The new realm name displays the next time you log on to the ProxySG Management Console. 

2. (Optional) View the results. As the show security command displays lengthy output, only the 
relevant section is displayed in the following example: 

SGOS# (config) show security 
Account : 

Username: "admin" 

Hashed Password: $l$aWMpN$/dsvVrZK6R68KH8r2SQxt/ 

Hashed Enable Password: $l$P4lpm$ZqFXg4 J4A/T . ORgUbrOB/1 
Hashed Front Panel PIN: " $l$GGSf2$lEhLm9oITgny9PDF2kVFp . " 

Management console display realm name: "" 

Management console auto-logout timeout: Never 

You can negate the security management display-realm values by entering no before the 
command; for example, security management no display-realm. 

Changing the ProxySG Timeout 

The timeout is the length of time a session persists before you are logged out. The default timeout is 
900 seconds (15 minutes). 

To Change the Timeout through the Management Console 

1. Select Configuration>Authentication>Console Access>Console Account. 

The Console Account tab displays. 

2. Either deselect Enforce auto-logout (which eliminates auto-logout entirely) or change the 
auto-logout timeout from its default of 900 seconds (15 minutes) to another time (in seconds). This 
is the allowable time on the ProxySG before the current session times out. Acceptable values are 
between 300 and 86400 seconds (5 minutes to 24 hours). 

If you change the timeout value, the change takes effect on the next refresh of any applet on the 
Management Console. 
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3. Click Apply. 

To Change the Timeout through the CLI 

1. To change the timeout from its default of 900 seconds (15 minutes), enter: 

SGOS# (config) security management auto -logout -timeout seconds 

The change takes effect on the next refresh of any applet in the Management Console. Acceptable 
values are between 300 and 86400 seconds (5 minutes to 24 hours). 

2. (Optional) View the results. As the show security command displays lengthy output, only the 
relevant section is displayed in the following example: 

SGOS# (config) show security 
Account : 

Username: "admin" 

Hashed Password: $l$a2zTlEE$lb88R3SXUTXS . zO71h8db0 
Hashed Enable Password: $l$xQnqGerX$LU65b2 0trsIAF6yJox26L . 

Hashed Front Panel PIN: " $l$ThSEiBlv$seyBhSxtTXEtUGDZ5NOBl/ " 

Management console display realm name: "Aurora" 

Management console auto-logout timeout: Never 

You can negate the security management auto- logout -timeout values by entering no 
before the command; for example, security management no auto-logout-timeout. 

Configuring the SSH Console 

By default, the ProxySG uses Secure Shell (SSH) and password authentication so administrators can 
access the ProxySG CLI or Management Console securely. SSH is a protocol for secure remote logon 
over an insecure network. No action is required unless you want to change the existing SSH host key, 
disable a version of SSH, or import RSA host keys. Only one SSH service is allowed on the ProxySG. 

To disable the SSH port, see "Managing the SSH Host Connection" below. 

Managing the SSH Host Connection 

You can manage the SSH host connection through either the Management Console or the CLI. 

To Manage the SSH Connection through the Management Console 



Note: Only one SSH Console can be enabled at a time. By default, both SSHvl and SSHv2 are 

enabled and assigned to port 22. You do not need to create a new host key unless you 
want to change the existing configuration. 



1. Select Configuration>Services>SSH Console>SSH Host. 
The SSH Host tab displays. 
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SSH Host SSH Client | 

r SSH VI 



[ Create ] 

I Delete I 



r SSHV2 

I Create I 

[ Delete | 



ssh-rsa AAAAB3NzaClyc2EAAAABIwAAAIEA06c0 j3N24HQBI+4q 
epVnz I T ac OnCMc j rW9 iKC 5KS v6 P C GO i 1 Y7HX J 1128 SWU j mb Rul 9 f 
GNz P iM/uwsNenzwsbt t q7y C 7HH9 T x¥URM6 i GXdC 6 an6 cp IWngl e s 
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Figure 3-6: SSH Host Tab 

2. To delete either SSHvl or SSHv2 support on the ProxySG, click the appropriate Delete button. 
The change is made on the ProxySG instantly. 



Important: Do not delete both versions. This disables the SSH Console. Even if you add SSHvl 

or SSHv2 client keys back, you will have to enable the service through 
Configuration>Services>Service Ports. 



The SSH host tab redisplays with the appropriate host key deleted. 

3. To add SSHvl or v2 support, select the Create checkbox for the version you want. Remember that 
if both versions are deleted, you must re-enable the SSH service on port 22. 

4. The SSH host key displays in the appropriate pane. 

To Manage SSH Host Keys through the CLI 



Note: Only one SSH Console can be enabled at a time. By default, both SSHvl and SSHv2 are 

enabled and set up on port 22. You do not need to create a new host key unless you want 
to change the existing configuration. In fact, you cannot create a new host key unless you 
delete one of the existing client keys. 



You must set up RSA client keys to connect to the ProxySG using RSA. To set up RSA client keys, see 
"Managing the SSH Client" below. 

1. From the (conf ig) prompt of the ProxySG, enter the following commands to create a host key. 

SGOS# (config) services 

SGOS# (config services) ssh-console 

SGOS# (config services ssh-console) create host-keypair [sshvl | sshv2] 

The client key, either SSHvl or SSHv2 or both, is created, depending on which client key was 
previously deleted. 
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2. (Optional) View the results. 

SGOS# (config services ssh-console) view host-public-key [sshvl | sshv2] 

1024 35 

190118975106704546356706163851813093052627858203406609264841510464285480824 

068799445880489701889675368436600545643174140823440610328520806007156774811 

989754027101280816905716431491183274963949027032871437205903863441301419664 

1366408168414061584835486361481236628643756053169543839452802141370496747163 

3977037 

ssh-rsa 

AAAAB3NzaClyc2EAAAABIwAAAIEA2rSeDb3vhr78AFmd7TbdtziYfUQybaDxdMBbSLuyJVgwVbq+ 
tIvS4L6kDsTuFYGVR8Cg74Xqs j 2kO6iwo71YGwdUnDXEzIFBwl0nvS4LkV2UINUwbuP0R0hD4Dt 
j VTKsURrOHbTxcXkFipplDwFPDiCKOIqLm4ypcaC/P j + Juq0 = 

3. To disable SSH, enter: 

SGOS# (config services ssh-console) delete host-keypair [sshvl | sshv2] 

Deleting both of the client keys disables the SSH service on port 22, which then must be 
re-enabled before you can use SSH Console services again, even if you re-create the host 
keys. 

Managing the SSH Client 

You can have multiple RSA client keys on the ProxySG to allow for actions such as logging on to the 
ProxySG from different locations. You cannot create an RSA client key through the appliance, only 
through an SSH client. Many SSH clients are commercially available for UNIX and Windows. 

Once you have created an RSA client key following the instructions of your SSH client, you can import 
the key onto the ProxySG using either the Management Console or the CLI. 

Understanding OpenSSH.pub Format 

Blue Coat supports the OpenSSH.pub format. Keys created in other formats will not work. 

An OpenSSH.pub public key is similar to the following: 

ssh-rsa 

AAAAB3NzaClyc2EAAAABIwAAAIEAwFI78MKyvL8DrFgcVxpNRHMFKJrBMeBn2PKcv5oAJ2qz+uZ7 
hiv7Zn43A6hXwY+DekhtNLOk3HCWmgsrDBE/NOOEnDpLQ jBC6t/T3cSQKZ jh3NmBbpE4U49rPdu 
iiufvWkuoEiHUb5ylzRGdXRSNJHxxmg5LiGEiKaoELJf sDMc= user@machine 

One of the public key format examples (this one created by the SSH client) is similar to the following: 

BEGIN SSH2 PUBLIC KEY 

Comment: "[1024-bit rsa, user . name®machine , Wed Feb 19 2003 19:2\8:09]" 
AAAAB3NzaClyc2EAAAADAQABAAAAgQCw52JeWr6Fv4kLkzbPZePvapCpaTadPYQwqsGnCIYdflW 
e7/8336EmzV918Gljb/VTlSIltMlKulBTal7uWAi+aUBGKLlYuyhCTo03IZFMnsQC7QYzYly3ju 
fUP3H0be52f g7n7p7gNZRllyzWhVeilvIKiyVKp j qiq6hxCbMb2Q= = 

END SSH2 PUBLIC KEY 

The OpenSSH.pub format appends a space and a user ID to the end of the client key. 

The user ID for the key must be unique. Because the ProxySG manages the keys through the user, no 
two can be the same. 

Other caveats: 
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□ 1024 bits is the maximum supported key size. 

□ An ssh-rsa prefix must be present. 

□ Trailing newline characters must be removed from the key before it is imported. 

To Import RSA Client Keys through the Management Console 

1. From your SSH client, create a client key and copy it to the clipboard. 

Note: The above step must be done with your SSH client. The ProxySG cannot create client 

keys. 



2. Select Configuration>Services>SSH Console>SSH Client. 
The SSH Client tab displays. 

SSH Host SSH Client 

- Import Client Key 

Import I New SSH Client Key 




Figure 3-7: SSH Client Tab 
3. Click Import to import a new host key. 
The Import Client Key dialog displays. 



Import Client Key 



iiiipuu iNcy iui. 

(• New User 



C Existing User 



21 



Client key: 



OK | Cancel | 

Figure 3-8: Import Client Key Dialog 
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4. Specify whether the client key is associated with an existing user or a new user, and enter the 
name. 

5. Paste the RSA key that you previously created with an SSH client into the Client key field. Ensure 
that a key ID is included at the end. Otherwise, the import fails. 

6. Click OK. 

The SSH Client tab reappears, with the fingerprint of the imported key displayed. 

SSH Host SSH Client 

- Import Client Key 

| import | New SSH Client Key 




Figure 3-9: SSH Client with Imported Client Key 
To Import a Client Key through the CLI 

1. From your SSH client, create a client key and copy it to the clipboard. 

2. From the (config) prompt, enter the following commands to import a client key. 

SGOS# (config) services 

SGOS# (config services) ssh-console 

SGOS# (config ssh-console) import client-key username 
Paste client key here, end with (three periods) 

ssh-rsaAAAAB3NzaClyc2EAAAABIwAAAIEAtAy+axsx0iwroFN7B9qS JYj fVbsxPfyCOaoZpSMBd 
g97/oiFozDXPhrRmPI3c42EiVdJtVo65r0Aerpu4ybCYVeq6Mj RwdsszaezY+VdqtfyYVptC6Vl 
7Pmj2erw4+A9AggKHTp56BBCm3mEPQDdVW7J6QBrJ+UlClFS/sMcbV8=laptop@GLYPH 

ok 

3. (Optional) View the results. 

SGOS# (config services ssh-console) view client-key username 
user_ID@PC 45:5C:3F:5F: EA : 65 : 6E : CF : EE : 4A : 05 : 58 : 9A : C5 : FB : 4F 
user ID@LAPTOP 61 : ED : 79 : 23 : F5 : 2A: 1A : 6D : 84 : 81 : AO : 5B : 25 : 36 : C7 : 5F 



Note: If you have upgraded from an older version ProxySG, and you want to view a previously 

imported client key, you might not need to enter a username. 
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This chapter describes how to configure various ProxySG system configurations, such as setting the 
time, configuring adapters, and creating software bridges. 

This chapter contains the following sections: 

□ "Global Configurations" 

□ "Archive Configuration" 

□ "Adapters” 

□ "Software and Hardware Bridges" 

□ "Gateways" 

□ "Defining Static Routes" 

O "Using RIP" 

□ "DNS Servers" 

□ "Attack Detection" 

□ "Using a Bypass List” 

□ "Installing WCCP Settings” 

□ "Virtual IP Addresses" 

□ "Configuring Failover" 
n "TCP/IP Configuration" 

During initial configuration. Interface 0 was configured by default. The NTP server was defined to 
keep the system time correct. You also optionally configured a bridge, a gateway, and a DNS server. 

These configurations require no further modification. These procedures are provided if you need to 
configure other adapters in the system or if the need to change a configuration occurs. 
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Section A: Global Configurations 

The ProxySG global configurations include: defining the ProxySG name and serial number, setting the 
time, and configuring NTP for your environment. 

The following topics are discussed in this section: 

□ "Configuring the ProxySG Name" 

□ "Configuring the Serial Number” 

□ "Configuring the System Time" 

□ "Network Time Protocol" 

□ "Configuring HTTP Timeout" 

Configuring the ProxySG Name 

You can assign any name to a ProxySG. A descriptive name helps identify the system. 

To Set the ProxySG Name through the Management Console 

1. Select Configuration>General>ldentification. 

The Identification tab displays. 

Identification 

- Unique name for this ProxySG Appliance: 

Name: 10.9.59.243 - Blue Coat SG110 

- Serial number of fhe ProxySG Appliance: 

Serial number: 

Figure 4-1 : General Identification Tab 

2. In the Unique name for this ProxySG Appliance field, enter a ProxySG name. 

3. Click Apply. 

To Set the ProxySG Name through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) hostname name 

Configuring the Serial Number 

The ProxySG serial number assists Blue Coat Systems Customer Support when analyzing 
configuration information, including heartbeat reports. This number is found on the ProxySG. Once 
the serial number is entered, the ProxySG does not verify the validity of the number, only that it is 
numeric. 
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Note: If the EPROM contains the ProxySG serial number, you cannot manually enter a serial 

number. 



To Enter the Serial Number through the Management Console 

1. Select Configuration>General>ldentification. 

The Identification tab displays. 

2. In the Serial Number field, enter the serial number. 

3. Click Apply. 

To Enter the Serial Number through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) serial -number serial_number 

Displayed Information 

The serial number is visible on the Management Console home page, and is displayed using the show 
serial -number command. If the serial number was entered through the Management Console or the 
CLI, it is appended with (configured) to indicate a manual entry. 

Configuring the System Time 

To manage objects, the Blue Coat appliance must know the current Coordinated Universal Time 
(UTC), which is the international time standard and is based on a 24-hour clock. However, time 
stamps can also record in local time. To do this, local time must also be set based on time zones. 

By default, the Blue Coat appliance attempts to connect to an NTP server, in the order the servers 
appear in the NTP server list on the NTP tab, to acquire the UTC time. The appliance ships with a list 
of NTP servers available on the Internet. If the appliance cannot access any of the listed NTP servers, 
you must manually set the UTC time. 

Additionally, the Blue Coat appliance ships with a limited list of time zones. If a particular time zone 
is missing from the included list, the list can be updated at your discretion. Also, the time zone 
database may need to be updated if the Daylight Savings rules change in your area. The list can be 
updated by downloading the full time zone database from 
http://download.bluecoat.com/release/timezones.tar. 

To Set Local Time through the Management Console 
1. Select Configuration>General>Clock>Clock. 

The Clock tab displays. 
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Clock | NTP 

r Current time: 



UTC: 


| 18:05:22 


ir 


13 Feb 2007 


Sync 


Local: 


| 10:05:22 


ii 


13 Feb 2007 




Timezone: 


| America/Los_Angel 


les 


] [ 


Set Time zone 



Update time zone database 



Installation URL: http:// 



Install 



Set to default 



- Method for acquiring UTC: 

0 Enable NTP I Acquire UTC time | 

Query interval (minutes) 60 

Figure 4-2: General Clock Tab 



2. Click Select Time zone. A popup appears, displaying a list of time zones based on geopolitical 
regions. 



Time zone selection 






ffl-laa Pacific 
_J America 
[••• Anchorage 



|Los_Angeles 



Denver 
Phoenix 
Regina 
Chicago 
Mexico_City 
New_York 
Bogota 
+i _J Indiana 
Halifax 
i La_Paz 

< 



Alaska Time 



Pacific Time 



Mountain Time 

Mountain Standard Time - Arizona 
Central Standard Time - Saskatchewar 
Central Time 

Central Time - most locations 
Eastern Time 



Atlantic Time - Nova Scotia (most pJ 



> 



OK ~| [ Cancel | 

Figure 4-3: Time Zone List 

3. Select the time zone that represents your local time. Once the local time zone is selected, event 
logs record the local time instead of GMT. To add additional time zones to the list, update the 
appliance's time zone database, as described in the following procedure. 



To Update the Time Zone Database: 

1. Select Configuration > General > Clock > Clock. 

2. Enter the URL from which the database will be downloaded or click Set to default. 

3. Click Install. 
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Related CLI Syntax for Adding New Time Zones to the Database: 

SGOS# (config) timezone database-path [url / default] 

SG0S# (config) load timezone-database 

To Acquire the UTC: 

1. Ensure that Enable NTP is selected. 

2. Click Acquire UTC Time. 

Related CLI Syntax for Acquiring and Setting UTC Time: 

SGOS# acquire-utc 

SGOS# (config) clock [subcommands] 

To Manually Set UTC Time through the Management Console 

1. Select Configuration>General>Clock>Clock. 

The Clock tab displays. 

2. De-select Enable NTP. 

The UTC time and date fields become editable when NTP is disabled. 

3. To set local time, click Select Time zone. A popup appears, displaying a list of time zones based on 
geopolitical regions.Click Pause in the upper-right-hand comer to stop the system clock. 

4. Enter the current UTC time and date in the UTC time and date fields. 

5. Click Resume to start the system clock. 

6. Click Apply. 

To Manually Set UTC Time through the CLI 

1. At the (config) command prompt, enter the following commands 

SGOS# (config) clock day 1-31 
SGOS# (config) clock hour 0-23 
SGOS# (config) clock minute 0-59 
SGOS# (config) clock month 1-12 
SGOS# (config) clock second 0-59 
SGOS# (config) clock year year 

2. (Optional) View the results. 

SGOS# (config) show clock 

2003-08-28 22 : 50 : 56+00 : 00UTC 
2003-08-28 22 : 50 : 56+00 : 00UTC 

Network Time Protocol 

The Network Time Protocol (NTP) is used to synchronize the time of a computer client or server to 
another server or reference time source, such as a radio or satellite receiver or modem. There are more 
than 230 primary time servers, synchronized by radio, satellite and modem. 
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The ProxySG ships a list of NTP servers available on the Internet, and attempts to connect to them in 
the order they appear in the NTP server list on the NTP tab. You can add others, delete NTP servers, 
and reorder the NTP server list to give a specific NTP server priority over others. 

The ProxySG uses NTP and the Universal Time Coordinates (UTC) to keep the system time accurate. 

You can add and reorder the list of NTP servers the ProxySG uses for acquiring the time through the 
Management Console. The reorder feature is not available through the CLI. 

To Add an NTP Server through the Management Console 

1. Select Configuration>General>Clock>NTP. 

The NTP tab displays. 

Clock NTP 

i- NTP servers: 




List order indicates preference [ Promote entry J 

| Demote entry ] 

Figure 4-4: General Clock NTP Tab 

2. Click New to add a new server to the list. 

3. Enter either the domain name or IP address of the NTP server and click OK. 

4. Click Apply. 

To Add an NTP Server through the CLI 

1. At the (config) command prompt, enter: 

SGOS# (config) ntp server domain_name 
SGOS# (config) ntp interval minutes 
SGOS# (config) ntp enable 

2. (Optional) View the results. 

SGOS# (config) show ntp 
NTP is enabled 
NTP servers : 

ntp . bluecoat . com 
ntp2 . bluecoat . com 
Query NTP server every 60 minutes 

3. To remove a server from the NTP server list: 
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SGOS# (config) ntp no server domain_name 

To Change the Access Order through the Management Console 

NTP servers are accessed in the order displayed. You can organize the list of servers so the preferred 
server appears at the top of the list. This feature is not available through the CLI. 

1. Select Configuration>General>Clock>NTP. 

The NTP tab displays. 

2. Select an NTP server to promote or demote. 

3. Click Promote entry or Demote entry as appropriate. 

4. Click Apply. 

Configuring HTTP Timeout 

You can configure various network receive timeout settings for HTTP transactions. You can also 
configure the maximum time that the HTTP proxy waits before reusing a client-side or server-side 
persistent connection. You must use the CLI to configure these settings. 

To Configure the HTTP Receive Timeout Setting through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) http receive-timeout {client | refresh | server} #_seconds 



where: 



client 


#_seconds 


Sets the receive timeout for client to #_seconds. The 
default is 120 seconds. 


refresh 


#_seconds 


Sets receive timeout for refresh to # seconds. The default 
is 90 seconds. 


server 


#_seconds 


Sets receive timeout for server to # seconds. The default 
is 180 seconds. 



To Configure the HTTP Persistent Timeout Setting through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) http persistent- timeout {client | server} #_seconds 



where: 



client 


#_seconds 


The maximum amount of time the HTTP proxy waits 
before closing the persistent client connection if another 
request is not made. The default is 360 seconds. 


server 


#_seconds 


The maximum amount of time the HTTP proxy waits 
before closing the persistent server connection if that 
connection is not re-used for any subsequent request 
from the proxy. The default is 900 seconds. 
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Section B: Archive Configuration 

Blue Coat allows you to both use an existing configuration (modified to include only general 
parameters, not system-specific settings) to quickly set up a newly-manufactured ProxySG and to 
save the running configuration off -box for archival purposes. 

This section discusses: 

□ "Sharing Configurations” 

□ "Archiving a Configuration" 

Sharing Configurations 

You can share configuration between two ProxySG Appliances. You can take a post-setup configuration 
file (one that does not include those configuration elements that are established in the setup console) 
from an already-configured ProxySG and push it to a newly-manufactured system. 



Note: Blue Coat Director allows you to push configuration from one ProxySG to multiple 

ProxySG Appliances at the same time. For more information on using Director, see 
Appendix F: "Using Blue Coat Director to Manage Multiple Appliances" on page 1141. 



The new configuration is applied to the existing configuration, changing any existing values. This 
means, for instance, that if the new configuration creates a realm called Realm A and the existing 
configuration has a realm called RealmB, the combined configuration includes two realms, RealmA and 
RealmB. 

You can use either the Management Console or the CLI to create a post-setup configuration file on one 
ProxySG and push it to another. 



Note: You cannot push configuration settings to a newly manufactured system until you have 

completed initial setup of the system. 



To Create and Push a Configuration to a Newly Manufactured ProxySG through the Management 
Console 

From the already configured ProxySG: 

1. Select Configuration>General>Archive. 

The Archive Configuration tab displays. 
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Archive Configuration 

- View Current Configuration 
View File: 



Configuration - post setup 



View 



r Install Configuration 



Install Configuration from: 



Local File v Install 



Figure 4-5: Archive Configuration Tab 



2. In the View Current Configuration panel, select the configuration from the drop-down list that you 
want to use for the newly-manufactured machine: 

• Configuration - post setup: This displays the configuration on the current system, minus any 
configurations created through the setup console, such as the hostname and IP address. It also 
includes the installable lists. 



• Configuration - brief: This displays the configuration on the current system, but does not include 
the installable lists. 



• Configuration - expanded: This is the most complete snapshot of the system configuration, but it 
contains system-specific settings that should not be pushed to a new system. 

• Results of Configuration Load: This displays the results of the last configuration pushed to the 
system. 

3. View the configuration you selected by clicking View. You can also view the file by selecting Text 
Editor in the Install Configuration panel and clicking Install. 

4. Save the configuration. You can save the file two ways: 

• Save it as a text file on your local system. This is advised if you want to re-use the file. 

• Copy the contents of the configuration. (You will paste the file into the Text Editor on the 
newly-manufactured system.) 

From the newly-manufactured ProxySG: 

1 . Launch the Management Console in a new browser window. 

2. Select Configuration>General>Archive. 

3. The Archive Configuration tab displays. 

4. In the Install Configuration panel, select either Local File or Text Editor from the drop-down list 
(depending on whether you saved the file to your system or just copied it to the clipboard) and 
click Install. 



• If you saved the file to your system, browse to the location of the Local File, highlight the file, 
and click Install. The configuration is installed, and the results screen displays. 

• If you copied the contents of the file, paste it into the Text Editor and click Install. The 
configuration is installed, and the results screen displays. 
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Note: A message is written to the event log when you install a list through the ProxySG. 



5. Click Close. 

To Create and Push a Configuration to a Newly Manufactured ProxySG through the CLI 

From the already configured ProxySG: 

1. From the enable prompt (#), determine which configuration you want to use for the new system. 
The syntax is: 

show configuration post-setup | brief | expanded 



where: 



Configuration - post setup 


This displays the configuration on the current system, minus any 
configurations created through the setup console, such as the 
hostname and IP address. It also includes the installable lists. 


Configuration - brief: 


This displays the configuration on the current system, but does not 
include the installable lists. 


Configuration - expanded 


This is the most complete snapshot of the system configuration, but it 
contains system-specific settings that should not be pushed to a new 
system. 



SGOS# show configuration post- setup 

The selected configuration displays on the screen. 

2. Save the configuration. You can save the file two ways: 

• Copy the contents of the configuration to the clipboard. (Paste the file into the terminal on the 
newly-manufactured system.) 

• Save it as a text file on a download FTP server accessible to the ProxySG. This is advised if you 
want to re-use the file. 

From the newly-manufactured ProxySG, do one of the following: 

□ If you saved the configuration to the clipboard, go to the ( conf ig) prompt and paste the 
configuration into the terminal. 

□ If you saved the configuration on the FTP server: 

At the enable command prompt, enter the following command: 

SGOS# configure network "url" 

where url must be in quotes and is fully-qualified (including the protocol, server name or 
IP address, path, and filename of the configuration file). The configuration file is 
downloaded from the server, and the ProxySG settings are updated. 
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Note: If you rename the archived configuration file so that it does not contain any spaces, 

the quotes surrounding the URL are unnecessary. 



The username and password used to connect to the FTP server can be embedded into the 
URL. The format of the URL is: 

ftp : //username : password@ftp- server 

where ftp -server is either the IP address or the DNS resolvable hostname of the FTP server. 

If you do not specify a username and password, the ProxySG assumes that an anonymous 
FTP is desired and thus sends the following as the credentials to connect to the FTP server: 

username : anonymous 
password: proxy@ 

Archiving a Configuration 

In the rare case of a complete system failure, restoring a ProxySG to its previous state is simplified by 
loading an archived system configuration from an FTP or TFTP server. The archive, taken from the 
running configuration, contains all system settings differing from system defaults, along with any 
installable lists configured on the ProxySG. 

Archive and restore operations must be done through the CLI. 



Note: You can archive a system configuration to an FTP or TFTP server that allows either 

anonymous logon or requires a specific username and password. Likewise, to restore a 
system configuration, the server storing the archive can be configured either to allow 
anonymous logon or to require a username and password. 



To Prepare to Archive a System Configuration 

1. Obtain write permission to a directory on an FTP server. This is where the archive will be stored. 
The system configuration must be stored using FTP. 

2. At the (config) command prompt, enter the following commands: 

SGOS# (config) archive-configuration protocol {ftp | tftp} 

SGOS# (config) archive-configuration host hostname 

where hostname is the IP address of the server. 



Note: TFTP does not require a password, path, or username. 

SGOS# (config) archive-configuration password password 
-or- 

SGOS# (config) archive-configuration encrypted-password encrypted-password 

where password is the password (or encrypted password) used to access the server. 
SGOS# (config) archive-configuration path path 
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where pa th is the directory on the server where the archive is to be stored, relative to the 
preset FTP directory. 

SGOS# (config) archive-configuration filename-prefix filename 

where filename can contain % strings that represent the information in the upload 
filename. If you do not use the filename command, the ProxySG creates a name with a 
timestamp and the filename SG_last-ip-octet_timestamp . For % string substitutions, 
see "Fields Available for Creating Access Log Formats" on page 1048. 

SGOS# (config) archive-configuration username username 

where user name is the username used to access the server. 



Example Session 



SGOS# (config) 
ok 

SGOS# (config) 
ok 

SGOS# (config) 
ok 

SGOS# (config) 
ok 

SGOS# (config) 
ok 



archive - configuration 
archive - configuration 
archive - configuration 
archive - configuration 
archive - configuration 



host 10.25.36.47 
password access 
username adminl 

path ftp : //archive . server/stored 
protocol ftp 



Note: To clear the host, password, or path, type the above commands using empty 

double-quotes instead of the variable. For example, to clear the path, enter 
archive-configuration path 



To Archive a System Configuration through the CLI 

At the enable command prompt, enter the following command: 
SGOS# upload configuration 



To Restore a System Configuration through the CLI 

At the enable command prompt, enter the following command: 

SGOS# configure network "url" 

where url must be in quotes and is fully-qualified (including the protocol, server name or 
IP address, path, and filename of the configuration file). The configuration file is 
downloaded from the server, and the ProxySG settings are updated. 



Note: If you rename the archived configuration file so that it does not contain any spaces, 

the quotes surrounding the URL are unnecessary. 



The username and password used to connect to the FTP server can be embedded into the URL. The 
format of the URL is: 

ftp : //username : password@ftp- server 
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where ftp- server is either the IP address or the DNS resolvable hostname of the FTP server. 

If you do not specify a username and password, the ProxySG assumes that an anonymous FTP is 
desired and thus sends the following as the credentials to connect to the FTP server: 

username : anonymous 
password: proxy@ 

Troubleshooting 

When pushing a shared configuration or restoring an archived configuration, keep in mind the 
following issues: 

□ Encrypted passwords (login, enable, and FTP) cannot be decrypted by a device other than that on 
which it was encrypted. If you were sharing a configuration, these encrypted passwords were 
probably already created before the configuration was pushed to the system. 

□ If the content filtering database has not yet been downloaded, any policy that references 
categories is not recognized. 

□ The following passwords must be re-created (if you use the application specified): 

• administrator console passwords (not needed for shared configurations) 

• privileged-mode (enable) passwords (not needed for shared configurations) 

• the front-panel PIN (recommended for limiting physical access to the system) 

• access log FTP client passwords (primary, alternate) 

• archive configuration FTP password 

• RADIUS primary and alternate secret 

• LDAP search password 

• SmartFilter download password 

• WebSense3 download password 

• SNMP read, write, and trap community strings 

• RADIUS and TACACS+ secrets for splash pages 

□ A full download of the content filtering database must be done. 

□ SSH certificate keys must be imported. 

□ SSL certificate keys must be imported 

In addition, you should make sure the system is functioning whenever you add a feature. For 
example, make sure the system works after basic configuration; then, after you add authentication, 
recheck the system. 
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Section C: Adapters 

This section describes ProxySG network adapters and the adapter interfaces. 



Note: In Blue Coat documentation, the convention for adapters and their interfaces (the 

connections on the adapter) is Adapter 0, Interface 0, or 0:0. 



This section discusses: 

□ "About Adapters" 

□ "Network Interface States" 

□ "Configuring an Adapter" 

□ "About the Settings Button" 

□ "Detecting Network Adapter Faults" 

About Adapters 

ProxySG Appliances ship with one or more network adapters installed on the system, each with one 
or more interfaces. You can change interface parameters or configure additional adapters in the 
appliance. You can also accept or reject inbound connections, change link settings in the event the 
system did not correctly determine them, and configure the browser for proxy settings. 



Network Interface States 

As you select adapters from the picklist, the Adapter panel (Configuration>Network>Adapters) displays 
the state of the configured adapter and its interfaces. When you initially set up the ProxySG, you 
optionally configured Adapter 0, Interface 0. If your system has only one adapter, you can skip this 
section. If your system shipped with other adapters, you can configure them through these 
procedures. 

Configuring an Adapter 

The following procedure describes how to configure an adapter. Repeat the process if the system has 
additional adapters. 

To Configure a Network Adapter through the Management Console 
1. Select Configuration>Network>Adapters>Adapters. 

The Adapters tab displays. 



Note: Different ProxySG models have different adapter configurations, and the appearance of 

the Adapters tab varies accordingly. 
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Adapters | Bridges 

- Adapters: 





r Interfaces: 



Interface 0 



Settings 



Interface 0 is not a member of any software bridge. 
IP address for interface 0: 



10 


9 


1 59 | 243 




255 


| 255 


| 255 | 0 



Figure 4-6: Network Adapters Tab 



2. Select an adapter from the Adapter drop-down list. 

Notice that in the Interfaces field, a message displays stating whether the interface belongs to a 
bridge. For more information about network bridging, see "Software and Hardware Bridges" on 
page 91. 

3. (Optional) If you have a dual interface adapter, select an interface from the drop-down list. 

4. Enter the IP address and subnet mask for the interface into the IP address for interface x and Subnet 
mask for interface x fields (where interface x refers to the interface selected in the Interfaces 
drop-down list.) 

5. (Optional) To configure link settings, restrict inbound connections, or set up browser proxy 
behavior for the adapter, select the adapter (under Interfaces) and click Settings. Enter any changes 
and click OK to close the Settings dialog. 



Note: The default is to permit all inbound connections. Link settings are automatically 

determined and should not need to be modified. The browser default is to use the proxy's 
default PAC file. (See "About the Settings Button" below for more information on link 
settings and inbound connections.) 



6. Click Apply. 

To Configure a Network Adapter through the CLI 

At the (config) command prompt, enter the following commands: 

SGOS# (config) interface fast-ethernet interface_number 

where interface_number is 0, 1, or n, up to one number less than the number of adapters in 
the system. 

SGOS# (config interface interface_# : 0) ip-address ip_address 
SGOS# (config interface interface_# : 0) subnet-mask subnet 
SGOS# (config interface interface_# : 0) exit 
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About the Settings Button 

The Settings button in the Interfaces field allows you to restrict inbound connections on the selected 
adapter, and to choose manual or automatic configuration of the adapter link settings. 

The default for Inbound connections is to permit all incoming connections. The link settings are 
automatically determined and should not normally require modification. 



Note: Rejecting inbound connections improperly, or manually configuring link settings 

improperly, can cause the ProxySG to malfunction. Make sure that you know the correct 
settings before attempting either of these. If the ProxySG fails to operate properly after 
changing these settings, contact Blue Coat Support. 



Rejecting Inbound Connections 

The default setting allows inbound connections on all network adapters. 

To Reject Inbound Connections through the Management Console 

1. Select Configuration>Network>Adapters>Adapters. 

2. Select an adapter from the Adapter drop-down list. 

The Adapters tab displays. 



Settings for adapter 0 



- Security 

O Reject inbound connections 

- Link Settings: 

0 Automatically sense link settings 
O Manually configure link settings 

Duplex: 

Speed: 

MAC address: 00D0B7B4D928 

[ OK | | Cancel | 

Figure 4-7: Settings for Individual Network Adapters 

3. Click Settings. 

4. To allow inbound connections, select the Accept inbound connections radio button. To reject 
inbound connections, select Reject inbound connections. 



- Browser configuration: 

Provide instructions for: 

O using a proxy 

0 using the proxy's default PAC file 
0 using the proxy's accelerated PAC file 
O using the PAC file at this URL: 
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5. Click OK to close the Settings dialog. 

6. Click Apply. 

To Reject Inbound Connections through the CLI 

At the (conf ig) command prompt, switch to the interface submode to enter the following 
commands: 

SGOS# (config) interface interface_# 

SGOS# (config interface interface_# : 0) no accept inbound 
SGOS# (config interface interface_# : 0) exit 

Manually Configuring Link Settings 

By default, the ProxySG automatically determines the link settings for all network adapters. If the 
device incorrectly identifies the network adapter, you can manually configure the link settings. 

To Manually Configure Link Settings through the Management Console 

1. Select Configuration>Network>Adapters>Adapters. 

The Adapters tab displays. 

2. Select an adapter from the Adapters drop-down list. 

3. Click Settings. 

4. Select Manually configure link settings. 

5. Select Half or Full duplex. 

6. Select the correct network speed. 

7. Click OK to close the Advanced Settings dialog. 

8. Click Apply. 

To Manually Configure Link Settings through the CLI 

At the (config) command prompt, enter the following commands: 

SGOS# (config) interface fast-ethernet interface_# 

SGOS# (config interface interface_# : 0) full-duplex | half-duplex 
SGOS# (config interface interface_#: 0) speed 10 | 100 | lgb 
SGOS# (config interface interface_# : 0 ) exit 

Setting Up Proxies 

To set up proxies, see "Configuring Proxies" on page 181. 

Detecting Network Adapter Faults 

The ProxySG can detect whether the network adapters in an appliance are functioning properly. If the 
appliance finds that an adapter is faulty, it stops using it. When the fault is remedied, the ProxySG 
detects the functioning adapter and uses it normally. 
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To determine whether an adapter is functioning properly: 

1. Check whether the link is active (that is, a cable is connected and both sides are up). 

2. Check the ratio of error packets to good packets: both sent and received. 

3. Check if packets have been sent without any packets received. 

If an adapter fault is detected, and the adapter has an IP address assigned to it, the ProxySG logs a 
severe event. When an adapter does not have an IP address, the appliance does not log an entry. 



90 



Chapter 4: Configuring the System 



Section D: Software and Hardware Bridges 

Section D: Software and Hardware Bridges 

This section describes the ProxySG hardware and software bridging capabilities. The following topics 
are discussed: 

□ "About Bridging” 

□ "About the Pass-Through Adapter" 

□ "ProxySG Prerequisites" 

□ "Setting Bandwidth Management for Bridging" 

□ "Configuring a Software Bridge" 

□ "Configuring Failover" 

□ "Static Forwarding Table Entries" 

About Bridging 

Network bridging through the ProxySG provides transparent proxy pass-through and failover 
support. This functionality allows ProxySG Appliances to be deployed in environments where L4 
switches and WCCP-capable routers are not feasible options. 



Important: Bridge interfaces cannot be used in WCCP configurations. If the configuration 

includes bridge interfaces, you will receive the following error if you attempt to load 
the WCCP configuration file: Interface 0:0 is member of a bridge 



The ProxySG provides bridging functionality by two methods: 

□ Software — A software, or dynamic, bridge is constructed using a set of installed interfaces. Within 
each logical bridge, interfaces can be assigned or removed. 

□ Hardware — A hardware, or pass-through, bridge uses a 10/100 dual interface Ethernet adapter. 
This type of bridge provides pass-through support. 

About the Pass-Through Adapter 

A pass-through adapter is a 10/100 dual interface Ethernet adapter designed by Blue Coat to provide an 
efficient fault-tolerant bridging solution. If this adapter is installed on an Blue Coat appliance, SGOS detects 
the adapter upon system bootup and automatically creates a bridge — the two Ethernet interfaces serve as the 
bridge ports. If the Blue Coat appliance is powered down or loses power for any reason, the bridge fails open; 
that is, Web traffic passes from one Ethernet interface to the other. Therefore, Web traffic is uninterrupted, but 
does not route through the appliance. 



Important: This scenario creates a security vulnerability. 
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Once power is restored to the Blue Coat appliance, the bridge comes back online and Web traffic is routed to 
the appliance and thus is subject to that appliance's configured features, policies, content scanning, and 
redirection instructions. Note that bridging supports only failover; it does not support load balancing. 

The following figure provides an example of how the ProxySG indicates that an installed adapter is a 
pass-through adapter. 



Adapters: 




Figure 4-8: Pass-through Adapter 



Note: The adapter state is displayed on Configuration>Network>Adapters>Adapters. 



ProxySG Prerequisites 

Before configuring a software bridge, the following conditions must be satisfied: 

□ Adapters — The adapters must of the same type. Although the software does not restrict you from 
configuring bridges with adapters of different types (10/100 or GIGE, for example), the resultant 
behavior is unpredictable. 

□ IP addresses — If the bridge already has an IP address configured, IP addresses must be removed 
from any of adapter interfaces to be added. If the bridge does not have an IP address configured, 
the bridge can inherit the IP address from the first interface to be added. 

Setting Bandwidth Management for Bridging 

After you have created and configured a bandwidth management class for bridging (see Chapter 10: 

"Bandwidth Management" on page 489), you can manage the bandwidth used by all bridges. 



Note: Before you can manage the bandwidth for bridging, you must first create a 

bandwidth-management class configured for bridging. See Chapter 10: "Bandwidth 
Management" on page 489 for information about creating and configuring the bandwidth 
class. 



To Configure Bandwidth Management for Bridging through the Management Console 
1. Select Configuration>Network>Adapters>Bridges. 

The Bridges tab displays. 
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Adapters 



Bridges 



Bridging Bandwidth Class : 




2. 

3. 





Figure 4-9: Bridges Tab 

In the Bridging Bandwidth Class drop-down menu, select a bandwidth management class to manage 
the bandwidth for bridging, or select <none> to disable bandwidth management for bridging. 

Click Apply. 



To Configure Bandwidth Management for Bridging through the CLI 

1. At the (config) command prompt, enter the following commands: 

SGOS# (config) bridge 

SGOS# (config bridge) bandwidth-class bw_class_name 

where bw_class_name designates the name of the bandwidth class that you have created and 
configured to manage the bandwidth for software bridging. 

2. (Optional) To disable bandwidth management for software bridging, enter the following 
command: 

SGOS# (config bridge) no bandwidth-class 



Configuring a Software Bridge 

This section describes how to use the Management Console or the CLI to link adapters and interfaces 
to create a network bridge. 

To Create and Configure a Software Bridge through the Management Console 

1. Select Configuration>Network>Adapters>Bridges. 

The Bridges tab displays. 

2. In the Software Bridges area, click Create. 

3. In the New Bridge Name field of the dialog that appears, enter a name for the bridge, up to 16 
characters; click OK. 
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4. In the Bridge IP Address field, enter the IP address of the interface you previously configured (see 
"Configuring an Adapter" on page 86). 

5. In the Bridge Subnet Mask field, enter the subnet mask of the interface. 

6. To add a port to the bridge: 

a. In the Ports field, click New; the Create port for bridge dialog appears. 

b. From the drop-down lists, select a port number and adapter interface number; click OK. 

c. By default, link settings are automatically sensed. To change the Duplex and Speed 
options, click Link Settings, select Manually configure link settings, and change as required. 

d. Click OK. 

7. To further customize the bridge: 

a. In the Software Bridges field, click Settings; the Settings for bridge dialog appears. 

b. In the Security field, the default is to accept inbound connections on this interface. To 
disallow inbound connections, select Reject inbound connections. 

c. The default browser instruction is to use the browser's default PAC file. To instruct the 
browser to use a proxy or other PAC file type, make a selection from the list in the Browser 
Configuration field. 

d. Click OK. 

8. Click Apply. 

The Bridge Settings options allow you to clear bridge forwarding table and clear bridge statistics. 

To Create or Edit a Software Bridge through the CLI 

1. To create a new software bridge, enter the following commands at the (conf ig) command 
prompt: 

SGOS# (config) bridge 

SGOS# (config bridge) create bridge_name 

where bridge_name designates the name of the new bridge. The limit is 16 characters. 

2. To edit the configuration of an existing software bridge, enter the following commands: 

SGOS# (config bridge) edit bridge_name 

where bridge_name designates the name of the bridge that you want to configure. The 
prompt changes to a submode for that bridge. 

SGOS# (config bridge bridge_name) ip-address ip_address 

where ip_address designates the IP address of the adapter interface you previously 
configured (see "Configuring an Adapter" on page 86). 

SGOS# (config bridge bridge_name ) subnet-mask subnet_mask 

where subnet_mask designates the subnet mask of the interface you previously configured. 

3. To configure a port on a bridge, enter the following commands (repeat to add more ports): 

SGOS# (config bridge bridge_name ) port port_number 

where port_number identifies a port on the interface. This changes the prompt to a submode 
for that port number on that bridge. 
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• To attach port to an interface or change the Duplex and Speed options, enter the following 
commands: 

SGOS# (config bridge bridge_name port port_number) attach-interface 
interface_number 

SGOS# (config bridge bridge_name port port_number) {full-duplex | 
half -duplex} 

SGOS# (config bridge bridge_name port port_number) speed {10 | 100 | lgb} 



where: 



attach- interface 


interface number 


Attaches an interface for this port. 


full-duplex 




Configures this port for full duplex. 


half -duplex 




Configures this port for half duplex. 


speed 


10 | 100 | lgb 


Configures speed for this port. 



SGOS# (config bridge bridge_name port port_number ) exit 
SGOS# (config bridge bridge_name) 

• By default, link settings are automatically sensed. To perform an auto-sense, enter the 
following command: 

SGOS# (config bridge bridge_name port port_number) link-autosense 

• Return to the bridge_name submode: 

SGOS# (config bridge bridge_name port port_number) exit 
SGOS# (config bridge bridge_name) 

4. To specify the maximum transmission unit (MTU), enter the following command: 

SGOS# (config bridge bridge_name ) mtu-size size 

where size is a value from 72 to 1500. 

5. The default is to accept inbound connections on this interface. To disallow inbound connections, 
enter the following command: 

SGOS# (config bridge bridge_name ) no accept- inbound 

6. The default browser instruction is to use the browser's default PAC file. To instruct to use a proxy 
or other PAC file type, enter the following command: 

SGOS# (config bridge bridge_name) instructions {proxy | default-pac | 
central-pac url | accelerated-pac } 



where: 



proxy 




Use a proxy. 


default-pac 




Use the Blue Coat default PAC file. 


central-pac 


url 


Use the PAC file specified at the given URL. 


accelerated-pac 




Use the proxy's accelerated PAC file. 
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Configuring Failover 

You can configure failover for software bridges, but not for hardware bridges. Failover is 
accomplished by creating virtual IP addresses on each proxy, creating a failover group, and attaching 
the bridge configuration. One of the proxies must be designated with a higher priority (a master 
proxy). 

Example 

The following example creates a bridging configuration with one bridge on standby. 



Note: This deployment requires a hub on both sides of the bridge or a switch capable of port 

mirroring. 



□ ProxySG A — software bridge IP address: 10.0.0.2. Create a virtual IP address and a failover 
group, and designate this group the master. 

ProxySG_A# (conf ig) virtual-ip address 10.0.0.4 

ProxySG_A# (conf ig) failover 

ProxySG_A# (conf ig failover) create 10.0.0.4 
ProxySG_A# (conf ig failover) edit 10.0.0.4 
ProxySG_A# (conf ig failover 10.0.0.3) master 
ProxySG_A# (conf ig failover 10.0.0.3) priority 100 
ProxySG_A# (conf ig failover 10.0.0.3) interval 1 

□ ProxySG B — software bridge IP address: 10.0.0.3. Create a virtual IP address and a failover 
group. 

ProxySG_B# (conf ig) virtual-ip address 10.0.0.4 

ProxySG_B# (conf ig) failover 

ProxySG_B# (conf ig failover) create 10.0.0.4 
ProxySG_B# (conf ig failover) edit 10.0.0.4 
ProxySG_B# (conf ig failover 10.0.0.3) priority 100 
ProxySG_B# (conf ig failover 10.0.0.3) interval 1 

□ In the bridge configuration on each ProxySG, attach the bridge configuration to the failover group: 

ProxySG_A# (conf ig bridge bridge_name ) failover 10.0.0.4 
ProxySG_B# (conf ig bridge bridge_name ) failover 10.0.0.4 

Static Forwarding Table Entries 

Certain firewall configurations require the use of static forwarding table entries. Failover 
configurations use virtual IP (VIP) addresses and virtual MAC (VMAC) addresses. When a client 
sends an ARP request to the firewall VIP, the firewall replies with a VMAC (which can be an Ethernet 
multicast address); however, when the firewall sends a packet, it uses a physical MAC address, not 
the VMAC. 

The solution is to create a static forwarding table entry that defines the next hop gateway that is on the 
correct side of the bridge. 
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To Create a Static Forwarding Table Entry through the CLI 

1. At the (config) prompt, enter the following commands: 

SGOS# (config) bridge 

SGOS# (config bridge) edit bridge_name 

SGOS# (config bridge bridge_name ) port port_number 

SGOS# (config bridge_name port port_number) static- fwtable-entry mac_address 
1 . Add up to 256 entries per bridge. 

To Clear a Static Forwarding Table Entry through the CLI 

At the (config) prompt, enter the following commands: 

SGOS# (config) bridge 

SGOS# (config bridge) edit bridge_name 

SGOS# (config bridge bridge_name) clear- fwtable 
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Section E: Gateways 

A key feature of the ProxySG is the ability to distribute traffic originating at the appliance through 
multiple gateways. You can also fine tune how the traffic is distributed to different gateways. This 
feature works with any routing protocol (such as static routes or RIP). 



Note: Load balancing through multiple gateways is independent from the per-interface load 

balancing the ProxySG automatically does when more than one network interface is 
installed. 



This section discusses: 

□ "About Gateways" 

□ "ProxySG Specifics" 

□ "Switching to a Secondary Gateway" 

□ "Defining Static Routes" 

About Gateways 

During the initial setup of the ProxySG, you optionally defined a gateway (a device that serves as 
entrance and exit into a communications network) for the ProxySG. 

By using multiple gateways, an administrator can assign a number of available gateways into a 
preference group and configure the load distribution to the gateways within the group. Multiple 
preference groups are supported. 

The gateway specified applies to all network adapters in the system. 

ProxySG Specifics 

Which gateway the ProxySG chooses to use at a given time is determined by how the administrator 
configures the assignment of preference groups to default gateways. You can define multiple 
gateways within the same preference group. A ProxySG can have from 1 to 10 preference groups. If 
you have only one gateway, it automatically has a weight of 100. 

Initially, all gateways in the lowest preference group are considered to be the active gateways. If a 
gateway becomes unreachable, it is dropped from the active gateway list, but the remaining gateways 
within the group continue to be used until they all become unreachable, or until an unreachable 
gateway in a lower preference group becomes reachable again. If all gateways in the lowest preference 
group become unreachable, the gateways in the next lowest preference group become the active 
gateways. 
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In addition to a preference group, each gateway within a group can be assigned a relative weight 
value from 1 to 100. The weight value determines how much bandwidth a gateway is given relative to 
the other gateways in the same group. For example, in a group with two gateways, assigning both 
gateways the same weight value, whether 1 or 100, results in the same traffic distribution pattern. In a 
group with two gateways, assigning one gateway a value of 10 and the other gateway a value of 20 
results in the ProxySG sending approximately twice the traffic to the gateway with a weight value of 
20. 

Switching to a Secondary Gateway 

When a gateway goes down, the ProxySG takes from 25 seconds to 120 seconds to determine that the 
gateway is unreachable. At that point, the ProxySG switches to a secondary gateway if one is 
configured. 

The check to determine whether a gateway has failed is done five times at five-second intervals once 
the route entry has aged for 90 seconds. The check to determine whether a gateway is now reachable 
is done every 10 seconds. 

These times are not user-configurable. 

To Configure Multiple Gateway Load Balancing through the Management Console 
1. Select Configuration>Network>Routing>Gateways. 

The Gateways tab displays. 

Gateways | Routing ] RIP 

- IP gateways: 




r IP Forwarding 1 

I | Enable IP forwarding 

Figure 4-10: Network Routing Gateways Tab and Add List Item Dialog 

2. Click New. 

3. Enter the IP address, group, and weight for the gateway into the Add list item dialog that appears. 

4. Click OK. 

5. Repeat steps 2 to 4 until IP addresses, groups, and weights have been defined for all of your 
gateways. 

6. Click Apply. 
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To Configure Multiple Gateway Load Balancing through the CLI 

1. At the (config) command prompt, enter the following command: 

SGOS# (config) ip-default-gateway ip_address preference_group weight 

The first value is the IP address of the gateway, the second value is the preference group, 
and the third value is the relative weighting for this gateway. For example, to use the 
gateway 10.25.36.1, the preference group l, and the relative weighting 100 , enter: 

ip-default-gateway 10.25.36.1 1 100 

2. Repeat until all IP addresses, groups, and weights of your IP gateways have been defined. 

3. (Optional) View the results. 

SGOS# (config) show ip-default-gateway 

Default IP gateways 

Gateway Weight Group 

10.25.36.1 100 1 

Defining Static Routes 

The ProxySG can be configured to use static routes, a manually-configured route that specifies the 
transmission path a packet must follow, based on the packet's destination address. A static route 
specifies a transmission path to another network. 



Note: You are limited to 10,000 entries in the static routes table. 



You can install the routing table several ways. 

□ Using the ProxySG Text Editor, which allows you to enter settings (or copy and paste the contents 
of an already-created file) directly onto the appliance. 

□ Creating a local file on your local system; the ProxySG can browse to the file and install it. 

□ Using a remote URL, where you place an already-created file on an FTP or HTTP server to be 
downloaded to the ProxySG. 

□ Using the CLI inline static-route-table command, which allows you to paste a static route 
table into the ProxySG. 

□ Using the CLI static-routes command, which requires that you place an already-created file on 
an FTP or HTTP server and enter the URL into the ProxySG. 

The routing table is a text file containing a list of IP addresses, subnet masks, and gateways. The 
following is a sample router table: 

10.25.36.0 255.255.255.0 10.25.46.57 

10.25.37.0 255.255.255.0 10.25.46.58 

10.25.38.0 255.255.255.0 10.25.46.59 

When a routing table is loaded, all requested URLs are compared to the list and routed based on the 
best match. 
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To Install a Routing Table through the Management Console 
1. Select Configuration>Network>Routing>Routing. 

The Routing tab displays. 



Gateways Routing 

I nstall R outing T able 



RIP 



Install Routing T able from: 



Remote URL v 



Install 



- View Routing Table 

Routing Table ~j View the current Routing T able 
[ Source | View source for the current Routing T able 

Figure 4-1 1 : Network Routing Tab 

2. From the drop-down list, select the method used to install the routing table; click Install. 
• Remote URL: 



Enter the fully-qualified URL, including the filename, where the routing table is located. To 
view the file before installing it, click View. Click Install. To view the installation results, click 
Results; close the window when you are finished. Click OK. 



Install Routing Table 



Install Routing Table 



Installation URL: 



Installation Status 



JnJiil 



Install | View | 



OK | Cancel | ^esullsj 

Figure 4-12: Specifying the Remote Location of a Routing Table 
• Local File: 

Click Browse to bring up the Local File Browse window. Browse for the file on the local 
system. Open it and click Install. When the installation is complete, a results window opens. 
View the results and close the window. 
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BlueQCoat 

Systems 


Upload and Install File home support documentation loo out 





Upload and Install the Static Routing T able 

1 . Paste the file path into the box below or choose a file 
by clicking the Browse... button and opening the file. 

2. Click Install to upload and install the new file. It can 
take some time for the upload to complete. Your 
browser may be unresponsive during the upload. 

3. Once the installation is completed the results will be 
displayed in a new page. Close the results page once 
you have finished viewing the results. 

File to upload: 

Browse... 



Install | Close | 

Figure 4-13: Specifying the Local Location of a Routing Table 
• Text Editor: 

The current configuration is displayed in installable list format. You can customize it or delete 
it and create your own. Click Install. When the installation is complete, a results window 
opens. View the results, close this window, and click Close. 
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Figure 4-14: Creating a Static Routing Table on the Proxy SG 
3. Click Apply. 

Installing a Routing Table Through the CLI 

To install a routing table through the CLI, you can use the inline command to install the table 
directly, or enter a path to a remote URL that has an already-created text file ready to download. 

When entering input for the inline command, you can correct mistakes on the current line using the 
<Backspace> key. If you detect a mistake in a line that has already been terminated using the <Enter> 
key, you can abort the inline command by typing <Ctrl-c>. If the mistake is detected after you 
terminate input to the inline command, type the same inline command again, but with the correct 
configuration information. The corrected information replaces the information from the last inline 
command. 

The end-of-input marker is an arbitrary string chosen by the you to mark the end of input for the 
current inline command. The string can be composed of standard characters and numbers, but 
cannot contain any spaces, punctuation marks, or other symbols. 

Take care to choose a unique end-of-input string that does not match any string of characters in the 
configuration information. 
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To Install a Routing Table through the CLI 

Do one of the following: 

□ To paste a static route table directly into the CLI, enter the following command at the (conf ig) 
command prompt, then paste the table on the line after the first end-of-file marker: 

SGOS# (config) inline static-route-table end-of-file_marker 
paste static routing table 
eof 
ok 

□ To enter the static route table manually, enter the following command, then enter each IP 
address/subnet on the second line, following the first end-of-file marker: 

SGOS# (config) inline static-route-table end-of-file_marker 

10 . 25 . 36.0 255 . 255 . 255.0 10 . 25 . 46.57 

10 . 25 . 37.0 255 . 255 . 255.0 10 . 25 . 46.58 

10 . 25 . 38.0 255 . 255 . 255.0 10 . 25 . 46.59 

eof 

ok 

□ To enter a path to a remote URL where you have placed an already-created static route table, enter 
the following commands at the (config) command prompt: 

SGOS# (config) static-routes path url 
SGOS# (config) load static-route-table 
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Section F: Using RIP 

The Routing Information Protocol (RIP) is designed to select the fastest route to a destination. RIP 
support is built into the ProxySG, and is configured by created and installing an RIP configuration text 
file onto the ProxySG. 

Blue Coat's RIP implementation also supports advertising default gateways. Default routes added by 
RIP are treated the same as the static default routes; that is, the default route load balancing schemes 
apply to the default routes from RIP as well. 

This section discusses 

□ "Installing RIP Configuration Files" 

□ "Configuring Advertising Default Routes” 

Installing RIP Configuration Files 

No RIP configuration file is shipped with the appliance. For commands that can be entered into the 
RIP configuration file, see Appendix D: "RIP Commands" on page 1117. 

Once you have created an RIP configuration file, you can install it several ways: 

□ Using the ProxySG Text Editor, which allows you to enter settings (or copy and paste the contents 
of an already-created file) directly onto the appliance. 

□ Creating a local file on your local system; the ProxySG can browse to the file and install it. 

□ Using a remote URL, where you place an already-created file on an FTP or HTTP server to be 
downloaded to the ProxySG. 

□ Using the CLI inline rip-settings command, which allows you to paste the RIP settings into 
the CLI. 

□ Using the CLI rip commands, which require that you place an already-created file on an FTP or 
HTTP server and enter the URL into the CLI. You can also enable or disable RIP with these 
commands. 

To Install an RIP Configuration File through the Management Console 



Note: When entering RIP settings that will change current settings (for instance, when 

switching from ripvl to ripv2), disable RIP before you change the settings; re-enable RIP 
when you have finished. 



1. Select Configuration>Network>Routing>RIP. 
The RIP tab displays. 
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Gateways | Routing 

- Install RIP Settings 

Install RIP Settings from: 



RIP 



Remote URL v 



Install 



f1 Enable RIP 



r View RIP 

RIP Settings | View the current RIP Settings 
RIP Routes | View the current RIP Routes 
Source ] View source for the current RIP 

Figure 4-15: Network Routing RIP Tab 

all of the View RIP buttons, 
used to install the routing table; 

click Install. 



2. To display the current RIP settings, routes, or source, click one or 

3. In the Install RIP Setting from the drop-down list, select the method 



• Remote URL: 

Enter the fully-qualified URL, including the filename, where the routing table is located. To 
view the file before installing it, click View. Click Install. To view the installation results, click 
Results; close the window when you are finished. Click OK. 




Figure 4-16: Specifying the Remote Location of a RIP Configuration File 
• Local File: 

Click Browse to display the Local File Browse window. Browse for the file on the local system. 
Open it and click Install. When the installation is complete, a results window opens. View the 
results and close the window. 
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Upload and Install File 



Upload and Install the RIP Settings 

1 . Paste the file path into the box below or choose a file 
by clicking the Browse... button and opening the file 

2 . Click Install to uplo ad and install the new file . It c an 
take some time for the upload to complete. Your 
browser may be unresponsive during the upload. 

3 . One e the installation is c omplete d the re suits will b e 
displayed in a new page. Close the results page once 
you have finished viewing the results. 



File to upload: 



Browse.. 



Figure 4-17: 
Text Editor: 



Install | Close | 

Specifying the Local Location of a RIP File 



The current configuration is displayed in installable list format. You can customize it or delete 
it and create your own. Click Install. When the installation is complete, a results window 
opens. View the results, close the window, and click OK. 
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BlueQCoat 

Systems 



Upload and Install File 



HOME SUPPORT DOCUI 



Edit and Install the RIP Settings 



1 . Edit the c ontents of the currently installe d file in the b ox b elo w. 

2. Click Install to upload and install the new contents. It can take some time for the upload to complete. 
Your browser may be unresponsive during the upload. 

3. Once the installation is completed the results will be displayed in a new page. Close the results page 
once you have finished viewing the results. 




Install Close 



Figure 4-18: Creating an RIP file on the ProxySG 



4. Click Apply. 

5. Select Enable RIP. 

6. Click Apply. 



Configuring RIP through the CLI 



Note: When entering RIP settings that will change current settings (for instance, when 

switching from ripvl to ripv2), disable RIP before you change the settings; re-enable RIP 
when you have finished. 



To Disable/Enable RIP through the CLI 

Enter the following command at the (config) command prompt: 
SGOS# (config) rip {disable | enable} 
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To Install an RIP Configuration through the CLI 

Do one of the following: 

□ To enter a path to a remote URL where you have placed an already-created RIP configuration file, 
enter the following commands at the (config) command prompt: 

SGOS# (config) rip path url 
SGOS# (config) load rip-settings 

□ To paste an RIP configuration directly into the CLI, enter the following command at the ( conf ig ) 
command prompt: 

SGOS# (config) inline rip-settings end-of-file_marker 

At this point you can paste RIP settings into the inline command, or you can enter 
values for specific settings. When you finish, enter your end-of-file_marker command. 

Example 

SGOS# (config) inline rip-settings eofm 

ripv2 
ripvl_out 
no_rdisc eofm 
ok 



Configuring Advertising Default Routes 

Default routes advertisements are treated the same as the static default routes; that is, the default 
route load balancing schemes also apply to the default routes from RIP. 

By default, RIP ignores the default routes advertisement. You can change the default from disable to 
enable and set the preference group and weight through the CLI only. This feature is not available 
through the Management Console. 

To Enable and Configure Advertising Default Gateway Routes 

1. At the (config) command prompt: 

SGOS# (config) rip default-route enable 

SGOS# (config) rip default-route group group_number 

SGOS# (config) rip default-route weight weight_number 

Where group_number defaults to 1, and weight_number defaults to 100, the same as the static 
default route set by the ip-default-gateway command. 

2. (Optional) To view the default advertising routes, enter: 

SGOS# (config) show rip default-route 

RIP default route settings: 

Enabled: Yes 

Preference group: 3 

Weight: 30 
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Section G: DNS Servers 

During first-time installation of the ProxySG, you configured the IP address of a single primary 
Domain Name Service (DNS) server. Using the Configuration>Network>DNS tab, you can change this 
primary DNS server at any time, and you can also define additional primary DNS servers and one or 
more alternate DNS servers. 

This section discusses: 

□ "ProxySG Specifics" 

□ "Configuring Split DNS Support" 

□ "Changing the Order of DNS Servers" 

□ "Unresolved Hostnames (Name Imputing)” 

□ "Changing the Order of DNS Name Imputing Suffixes" 

□ "Caching Negative Responses" 

ProxySG Specifics 

If you have defined more than one DNS server, the ProxySG uses the following logic to determine 
which servers are used to resolve a DNS host name and when to return an error to the client: 

□ The ProxySG first sends requests to DNS servers in the primary DNS server list. 

□ Servers are always contacted in the order in which they appear in a list. 

□ The next server in a list is only contacted if the ProxySG does not receive a response from the 
current server. 

□ If none of the servers in a list returns a response, the ProxySG returns an error to the client. 

□ The ProxySG only sends requests to servers in the alternate DNS server list if a server in the 
primary list indicates that a DNS host name cannot be resolved. 

If a DNS server returns any other error (other than an indication that a DNS host name could not 
be resolved), the ProxySG returns the error to the client. 

If a server in both the primary and alternate DNS server lists are unable to resolve a DNS host 
name, an error is returned to the client. 

The ProxySG always attempts to contact the first server in the primary DNS server. If a response is 
received from this server, no attempts are made to contact any other DNS servers in the primary list. 

If the response from the first primary DNS server indicates a name error, the ProxySG sends a DNS 
request to the first alternate DNS server, if one is defined. If no alternate DNS servers have been 
defined, an error is returned to the client indicating a name error. If the first alternate DNS server is 
unable to resolve the IP address, a name error is returned to the client, and no attempt is made to 
contact any other DNS servers in either the primary or alternate DNS server lists. 

If a response is not received from any DNS server in a particular DNS server list, the ProxySG sends a 
DNS request to the next server in the list. The ProxySG returns a name error to the client if none of the 
servers in a DNS server list responds to the DNS request. 
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Note: The alternate DNS server is not used as a failover DNS server. It is only used when DNS 

resolution of primary DNS server returns name error. If a timeout occurs when looking 
up the primary DNS server, no alternate DNS server is contacted. 



If the ProxySG receives a negative DNS response (a response with an error code set to Name Error), it 
caches that negative response. You can configure the ProxySGs negative response time-to-live value. 
(A value of zero disables negative caching.) If the ProxySG is not configured (the default), the 
ProxySG caches the negative response and uses the TTL value from the DNS response to determine 
how long it should be cached. 

Configuring Split DNS Support 

Customers with split DNS server configuration (for example, environments that maintain private 
internal DNS servers and external DNS servers) might choose to populate an Alternate DNS server 
list as well as the Primary DNS server list. In the ProxySG, the internal DNS servers are placed in the 
Primary list, while external DNS servers (with the Internet information) populate the Alternate list. 

Complete the following procedures to configure primary and alternate DNS servers. 

To Add a Primary DNS Server through the Management Console 
1. Select Configuration>Network>DNS>DNS. 

The DNS tab displays. 

DNS | Imputing 

r DNS servers: 




New | | Edit ~] | Delete 

List order indicates preference | Promote entry ] 

| Demote entry "| 

Primary DNS v 

Figure 4-19: Network DNS Tab and Add List Item Dialog 

2. Click New. 

3. Enter the IP address of the DNS server in the dialog that appears and click OK. 

4. Click Apply. 

To Add a Primary DNS Server through the CLI 

At the (config) command prompt, enter the following command: 



111 




Blue Coat ProxySG Configuration and Management Guide 



Section G: DNS Servers 

SGOS# (config) dns server ip_address 

To Add an Alternate DNS Server through the Management Console 

1. Select Configuration>Network>DNS>DNS. 

The DNS tab displays. 

2. Select Alternate DNS in the drop-down list. 

3. Click New. 

4. Enter the IP address of the DNS server in the dialog that appears and click OK. 

5. Click Apply. 

To Add an Alternate DNS Server through the CLI 

1. At the (config) command prompt, enter the following command: 

SGOS# (config) dns alternate ip_address 

2. Repeat until alternate DNS servers have been defined. 

Changing the Order of DNS Servers 

The ProxySG uses DNS servers in the order displayed. You can organize the list of servers so that the 
preferred servers appear at the top of the list. This functionality is not available through the CLI. 

To Change the Order of DNS Servers through the Management Console 
1. Select Configuration>Network>DNS>lmputing. 

The Imputing tab displays. 

DNS Imputing 

r DNS name imputing suffixes: 




List order indicates preference 

I Demote entry 

Figure 4-20: Network DNS Imputing Tab 

2. Select the DNS server to promote or demote. 

3. Click Promote entry or Demote entry as appropriate. 
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4. Click Apply. 

Unresolved Hostnames (Name Imputing) 

Name imputing allows the ProxySG to resolve host names based on a partial name specification. 
When the ProxySG submits a host name to the DNS server, the DNS server resolves the name to an IP 
address. The ProxySG queries the original hostname before checking imputing entries unless there is 
no period in the host name, in which case imputing is applied first. The ProxySG tries each entry in 
the name-imputing list until the name is resolved or it comes to the end of the list. If by the end of the 
list the name is not resolved, the ProxySG returns a DNS failure. 

For example, if the name-imputing list contains the entries company . com and com, and a user submits 
the URL http : / /www . eedept, the ProxySG resolves the host names in the following order. 

http : / /www . eedept 

http : / /www . eedept . company . com 

http : / /www . eedept . com 

To Add Names to the Imputing List through the Management Console 

1. Select Configuration>Network>DNS>lmputing. 

The Imputing tab displays. 

2. Click New to add a new name to the imputing list. 

3. Enter the name in the dialog that appears and click OK. 

4. Click Apply. 

To Add Names to the Imputing List through the CLI 

1. At the (config) command prompt, enter the following command: 

SGOS# (config) dns imputing suffix 

For example, to use company . com as the imputing suffix, enter dns - imputing company . com. 

2. Repeat until all imputing suffixes have been entered. 

Changing the Order of DNS Name Imputing Suffixes 

The ProxySG uses imputing suffixes in the order displayed. You can organize the list of suffixes so the 
preferred suffix appears at the top of the list. This functionality is only available through the 
Management Console. You cannot configure it through the CLI. 

To Change the Order DNS Name Imputing Suffixes through the Management Console 

1. Select Configuration>Network>DNS>lmputing. 

The Imputing tab displays. 

2. Select the imputing suffix to promote or demote. 

3. Click Promote entry or Demote entry as appropriate. 

4. Click Apply. 
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Caching Negative Responses 

By default, the ProxySG caches negative DNS responses sent by a DNS server. You can configure the 
ProxySG to set the time-to-live (TTL) value for a negative DNS response to be cached. You can also 
disable negative DNS response caching. 



Note: The ProxySG generates more DNS requests when negative caching is disabled. 



Both type A and type PTR DNS responses are affected by negative caching. 

This functionality is only available through the CLI. You cannot configure DNS negative caching 
through the Management Console. 

To Configure Negative Caching TTL Values 

From the (config) prompt: 

SGOS# (config) dns negative-cache-ttl-override seconds 

where seconds is any integer between 0 and 600. 

Setting the TTL value to 0 seconds disables negative DNS caching; setting the TTL setting to a 
non-zero value overrides the TTL value from the DNS response. 

To Restore Negative Caching Defaults 

From the (config) prompt): 

SGOS# (config) dns no negative-cache-ttl-override 
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Section H: Attack Detection 

The Proxy SG can reduce the effects of distributed denial of service (DDoS) attacks and port scanning, 
two of the most common virus infections. 

A DDoS attack occurs when a pool of machines that have been infected with a DDoS-type of virus 
attack a specific Web site. As the attack progresses, the target host shows decreased responsiveness 
and often stops responding. Legitimate HTTP traffic is unable to proceed because the ProxySG is still 
waiting for a response from the target host. 

Port scanning involves viruses attempting to self-propagate to other machines by arbitrarily trying to 
connect to other hosts on the Internet. If the randomly selected host is unavailable or behind a firewall 
or does not exist, the ProxySG continues to wait for a response, thus denying legitimate HTTP traffic. 

The ProxySG prevents attacks by limiting the number of simultaneous TCP connections from each 
client IP address and either does not respond to connection attempts from a client already at this limit 
or resets the connection. It also limits connections to servers known to be overloaded. 

You can configure attack detection for both clients and servers or server groups, such as 
http:/ /www.bluecoat.com. The client attack-detection configuration is used to control the behavior of 
virus-infected machines behind the ProxySG. The server attack-detection configuration is used when 
an administrator knows ahead of time that a virus is set to attack a specific host. 

This feature is only available through the CLI. You cannot use the Management Console to enable 
attack detection. 

This section discusses: 

□ "Configuring Attack-Detection Mode for the Client” 

□ "Configuring Attack-Detection Mode for a Server or Server Group" 

Configuring Attack-Detection Mode for the Client 

To Enter Attack-Detection Mode for the Client 

From the (config) prompt, enter the following commands: 

SGOS# (config) attack-detection 

SGOS# (config attack-detection) client 

The prompt changes to: 

SGOS# (config client) 

To Change Global Settings 

The following defaults are global settings, used if a client does not have specific limits set. They do not 
need to be changed for each IP address/ subnet if they already suit your environment: 

□ client limits enabled: true 

□ client interval: 20 minutes 

□ block-action: drop (for each client) 
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□ connection-limit: 100 (for each client) 

□ failure-limit: 50 (for each client) 

□ unblock-time: unlimited 

□ warning-limit: 10 (for each client) 

To Change the Global Defaults 

Remember that enable/ disable limits and interval affect all clients. The values cannot be changed for 
individual clients. Other limits can be modified on a per-client basis. 



Note: If you edit an existing client's limits to a smaller value, the new value only applies to new 

connections to that client. For example, if the old value was 10 simultaneous connections 
and the new value is 5, existing connections above 5 are not dropped. 



SGOS# (config client) enable-limits | disable-limits 

SGOS# (config client) interval minutes 

SGOS# (config client) block ip_address [ minutes ] | unblock ip_address 

SGOS# (config client) default block-action drop | send-tcp-rst 
SGOS# (config client) default connection-limit integer_between_l_and_65535 
SGOS# (config client) default failure-limit integer_between_l_and_500 
SGOS# (config client) default unblock-time minutes_between_10_and_1440 
SGOS# (config client) default warning- limit integer_between_l_and_100 



where: 



enable-limits | 
disable -limits 




Toggles between enabled and disabled. The default is 
disabled. This is a global setting and cannot be modified 
for individual clients. 


interval 


integer 


Indicates the amount of time, in multiples of 10 minutes, 
that client activity is monitored. The default is 20. This is a 
global setting and cannot be modified for individual 
clients. 


block | unblock 


ip address 
[ minutes ] 


Blocks a specific IP address for the number of minutes 
listed. If the optional minutes argument is omitted, the 
client is blocked until explicitly unblocked. Unblock 
releases a specific IP address. 


default 

block-action 


drop | 

send-tcp-rst 


Indicates the behavior when clients are at the maximum 
number of connections or exceed the warning limit: drop 
the connections that are over the limit or send TCP RST 
for connections over the limit. The default is drop. This 
limit can be modified on a per-client basis. 


default 

connect ion -limit 


integer 


Indicates the number of simultaneous connections 
between 1 and 65535. The default is 100. This limit can be 
modified on a per-client basis. 
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default 

failure-limit 


integer 


Indicates the maximum number of failed requests a client 
is allowed before the proxy starts issuing warnings. 
Default is 50. This limit can be modified on a per-client 
basis. 


default 

unblock-time 


minutes 


Indicates the amount of time a client is blocked at the 
network level when the client-warning-limit is exceeded. 
Time must be a multiple of 10 minutes, up to a maximum 
of 1440. The default is unlimited. This limit can be 
modified on a per-client basis. 


default 
warning- limit 


integer 


Indicates the number of warnings sent to the client before 
the client is blocked at the network level and the 
administrator is notified. The default is 10; the maximum 
is 100. This limit can be modified on a per-client basis. 



To Create and Edit a Client IP Address through the CLI 



1. Make sure you are in the attack-detection client submode. 

SGOS# (config) attack-detection 

SGOS# (config attack-detection) client 
SGOS# (config client) 



2. Create a client. 

SGOS# (config client) create client ip_address or ip_and_length 



3. Move to edit client submode. 

SGOS# (config client) edit client_ip_address 



The prompt changes to: 

SGOS# (config client ip_address ) 



4. 



Change the client limits as necessary. 

SGOS# (config client ip_address ) 
SGOS# (config client ip_address) 
SGOS# (config client ip_address) 
SGOS# (config client ip_address) 
SGOS# (config client ip_address ) 



block-action drop | send-tcp-rst 
connection- limit integer_between_l_and_6 5 53 5 
failure -limit integer_between_l_and_65535 

unblock-time minutes 

warning -limit integer_between_l_and_65535 



where: 



block-action 


drop | 

send-tcp-rst 


Indicates the behavior when the client is at the maximum 
number of connections: drop the connections that are over 
the limit or send TCP RST for the connection over the 
limit. The default is drop. 


connect ion -limit 


integer 


Indicates the number of simultaneous connections 
between 1 and 65535. The default is 100. 


failure-limit 


integer 


Indicates the behavior when the specified client is at the 
maximum number of connections: drop the connections 
that are over the limit or send TCP RST for the connection 
over the limit. The default is 50. 
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unblock-time 


minutes 


Indicates the amount of time a client is locked out at the 
network level when the client-warning-limit is exceeded. 
Time must be a multiple of 10 minutes, up to a maximum 
of 1440. The default is unlimited. 


warning- limit 


integer 


Indicates the number of warnings sent to the client before 
the client is locked out at the network level and the 
administrator is notified. The default is 10; the maximum 
is 100. 



To View the Specified Client Configuration 



Enter the following command from the edit client submode: 



SGOS#(config client ip_address) 
Client limits for 10.25.36.47: 
Client connection limit: 

Client failure limit: 

Client warning limit: 

Blocked client action: 

Client connection unblock time: 



view 

700 

50 

10 

Drop 

unlimited 



To View the Configuration for all Clients 

1. Exit from the edit client submode: 

SGOS# (config client ip_address ) exit 

2. Use the following syntax to view the client configuration: 
view <cr> [ blocked | connections | statistics 



To View All Settings 

SGOS# (config client) view 

Client limits enabled: true 

Client interval: 20 minutes 



Default client limits: 

Client connection limit: 100 

Client failure limit: 50 

Client warning limit: 10 

Blocked client action: Drop 

Client connection unblock time: unlimited 



Client limits for 10.25.36.47: 

Client connection limit: 700 

Client failure limit: 50 

Client warning limit: 10 

Blocked client action: Drop 

Client connection unblock time: unlimited 



118 



Chapter 4: Configuring the System 



Section H: Attack Detection 



To View the Number of Simultaneous Connections to the ProxySG 

SGOS# (config client) view connections 
Client IP Connection Count 



127 .0.0.1 1 

10.9.16.112 1 

10.2.11.133 1 



To View the Number of Blocked Clients 



SGOS# (config client) 
Client 
10.11.12. 13 
10.9.44.73 



view blocked 
Unblock time 

2004-07-09 22 : 03 : 06+00 : 00UTC 
Never 



To View Client Statistics 

SGOS# (config client) 
Client IP 
10.9.44.72 



view statistics 

Failure Count 



1 



Warning Count 
0 



To Disable Attack-Detection Mode for all Clients 

SGOS# (config client) disable-limits 



Configuring Attack-Detection Mode for a Server or Server Group 



You can create, edit, or delete a server. A server must be created before it can be edited. You can treat 
the server as an individual host or you can add other servers, creating a server group. All servers in 
the group have the same attack-detection parameters, meaning that if any server in the group gets the 
maximum number of simultaneous requests, all servers in the group are blocked. 

To Create a Server or Server Group 

1. At the (config) prompt, enter the following commands: 

SGOS# (config) attack-detection 

SGOS# (config attack-detection) server 

The prompt changes to: 

SGOS# (config server) 

2. Create the first host in a server group, using the fully qualified domain name: 

SGOS# (config server) create hostname 

To Edit a Server or Server Group 

At the (config server) prompt, enter the following commands: 

SGOS# (config server) edit hostname 

The prompt changes to (config server hostname ). 

SGOS# (config server hostname) {add | remove} hostname 

SGOS# (config server hostname ) request- limit integer_from_l_to_65535 
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where: 



hostname 




The name of a previously created server or server group. When 
adding a hostname to the group, the hostname does not have to 
be created. The host that was added when creating the group 
cannot be removed. 


add | remove 


hostname 


Adds or removes a server from this server group. 


request -limit 


integer 


Indicates the number of simultaneous requests allowed from this 
server or server group. The default is 1000. 



To View the Server or Server Group Configuration 

SGOS# (config server hostname ) view 
Server limits for hostname: 

Request limit: 1500 
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Section I: Using a Bypass List 

A bypass list can be used to completely skip all ProxySG processing of requests sent to specific 
destination hosts or subnets. This prevents the appliance from enforcing any policy on these requests 
and disables any caching of the corresponding responses, so it should be used with care. A bypass list 
allows traffic to pass through to sites as-is when servers at the site are not properly adhering to 
protocol standards or when the processing in the ProxySG is otherwise causing problems. 

The bypass list contains IP addresses, subnet masks, and gateways. When a request matches an IP 
address and subnet mask specification in the bypass list, the request is sent to the designated gateway 
and is not processed by the ProxySG. 



Note: Because a bypass list bypasses Blue Coat policy, bypass lists should be used sparingly 

only for specific situations. 



Blue Coat supports three types of bypass lists: local list, central list, and policy-based (dynamic 
bypass) list. The bypass lists all work together, or you can just create and maintain one. 



Note: The Local List and Central List are not the same as the Local Policy file and the Central 

Policy file. 



This section discusses: 

□ "Using the Local Bypass List” 

□ "Using the Central Bypass List" 

□ "Creating and Installing Local or Central Bypass Lists” 

□ "Using Policy to Configure Dynamic Bypass Lists" 

Using the Local Bypass List 

The local bypass list is one you create and maintain on your network. You can use a local bypass list 
alone, or in conjunction with a central list. 

The gateways specified in the bypass list must be on the same subnet as the ProxySG. The local bypass 
list limit is 10,000 entries. 

The local bypass list contains a list of IP addresses, subnet masks, and gateways. It can also define the 
default bypass gateway to be used by both the local bypass list and central bypass list. The gateways 
specified in the bypass list must be on the same subnet as the ProxySG. When you download a bypass 
list, the list is stored in the appliance until it is replaced by downloading a new list. 



Note: Because a bypass list bypasses Blue Coat policy, bypass lists should be used sparingly 

only for specific situations. 
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The following is a sample of a local bypass list: 



; define the default gateway for the local and central bypass list 



BYPASS GATEWAY 10.25.46.57 



; define addresses to bypass 



; I P address 

10.25.36.47 

10.25.36.48 
10.25.0.0 



subnet 

255.255.255.255 

255.255.255.255 

255.255.255.0 



gateway (or use default gateway) 



10.25.46.58 



If you do not specify the bypass_gateway and you do not designate the gateway in the address 
specification, the ProxySG forwards the request to the default gateway defined in the network 
configuration. 

For installation procedures for the local bypass list, see "Creating and Installing Local or Central 
Bypass Lists" on page 122. 



Using the Central Bypass List 

The central bypass list is usually a shared list of addresses that is used by multiple ProxySG 
Appliances. Because each ProxySG Appliance can be located on a different subnet and can be using 
different gateways, the central bypass list should not contain any gateway addresses. 

The gateway used for matches in the central bypass list is the gateway specified by the 
bypass_gateway command in the local bypass list. If there is no bypass_gateway option, the ProxySG 
uses the default gateway defined by the network configuration. 



Note: Because a bypass list bypasses Blue Coat policy, bypass lists should be used sparingly 

only for specific situations. 



You can create your own central bypass list to manage multiple ProxySG Appliances, or you can use 
the central bypass list maintained by Blue Coat Technical Support at: 

https : //download .bluecoat . com/ release/SG4/f iles/CentralBypassList . txt 



Note: The central bypass list is limited to 10,000 entries. 



You can select whether to download the list automatically when it changes or to receive an e-mail 
notifying you of the update. By default, neither is enabled. 

For installation procedures for the central bypass list, continue with the next section. 

Creating and Installing Local or Central Bypass Lists 

You can install the local and central bypass lists several ways: 

□ Use the ProxySG Text Editor, which allows you to enter the lists (or copy and paste the contents of 
an already-created file) directly onto the ProxySG through the Management Console (see the 
instructions below). 
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□ Create a local file on your local system; use the Management Console to browse to the file and 
install it (see the instructions below). 

□ Use a remote URL, where you place an already-created file on an FTP or HTTP server to be 
downloaded to the ProxySG. This can be done through either the Management Console or the CLI 
(see the instructions below). 

□ Use the CLI inline bypass-list {central | local} command, which allows you to paste the 
configurations onto the ProxySG (see the instructions below). For more information on using the 
CLI inline command, see "Using the Local Bypass List" on page 121 or "Using the Central Bypass 
List” on page 122. 

To Install Bypass Lists through the Management Console 

1. Select Configuration>Network>Advanced>Bypass List. 

The Bypass List tab displays. 

Bypass List WCCP I VIPs | Failover | 

- Install Bypass List Settings 



Install Local Bypass List from: 


Remote URL v 


Install 






Install Central Bypass List from: 


Remote URL v 


Install 



□ Automatically install new Bypass List when central file changes 

□ Send me email when central file changes 



- View Bypass List 

Bypass List | View the current Bypass List 
Source | View source for the current Bypass List 

Figure 4-21 : Bypass List Tab 

2. To view the current bypass list or the source for the current bypass list before installing it, click 
Bypass List or Source. 

3. (Optional) If installing the central bypass list, you can select whether to download the list 
automatically when it changes, or be sent an e-mail notifying you of the update. By default, 
neither is enabled. 

4. Select a method to install the file for either the local or central bypass list; click Install. 

• Remote URL: 

Enter the fully-qualified URL, including the filename, where the routing table is located. To 
view the file before installing it, click View. Click Install. View the installation status that 
displays; click OK. 
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< Install Local Bypass List 



Install Local Bypass List 
Installation URL: | http: 



Installation Status 



^JnjxJ 




OK | Cancel | Results | 

Figure 4-22: Specifying the Remote Location of a Local Bypass List Configuration File 
• Local File: 

Click Browse to bring up the Local File Browse window. Browse for the file on your local 
system. Open it and click Install. When the installation is complete, a results window opens. 
View the results, close the window, and click Close. 



BlueQCoat 

Systems 



Upload and Install File 



Upload and Install the Local Bypass List 



1 . Paste the file path into the box below or choose a file 
by clicking the Browse... button and opening the file. 

2 . Click Install to uplo ad and install the new file . It c an 
take some time for the upload to complete. Your 
browser may be unresponsive during the upload. 

3. Once the installation is completed the results will be 
displayed in a new page. Close the results page once 
you have finished viewing the results. 



File to upload: 

Browse... | 



HOME SUPPORT DOCUHt 



Install | Close | 



Figure 4-23: Specifying the Local Location of a Local Bypass List 



• Text Editor: 



The current configuration is displayed in installable list format. You can customize it or delete 
it and create your own. Click Install. When the installation is complete, a results window 
opens. View the results, close the window, and click Close. 
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BlueQCoat 

Systems 



Upload and Install File 



Edit and Install the Local By]) ass List 

1 . Edit the c ontents of the currently installe d file in the b ox b elo w. 

2. Click Install to upload and install the new contents. It can take some time for the upload to complete. 
Your browser may be unresponsive during the upload. 

3. Once the installation is completed the results will be displayed in a new page. Close the results page 
once you have finished viewing the results. 




Install 



Close 



Figure 4-24: Creating a Local Bypass List on the ProxySG 
5. Click Apply. 



To Install an Already Existing Bypass List through the CLI 

At the (config) command prompt, enter the following commands: 

SGOS# (config) bypass-list {local-path | central-path} url 
SGOS# (config) load bypass-list {local | central} 



To Install a Bypass List through the CLI inline Command 

At the (config) command prompt, enter the following command: 

SGOS# (config) inline bypass-list {local | central} end-of-file_marker 

At this point you can paste in local or central configuration files, or you can enter values 
for specific settings, such as server_bypass_threshold, max_dynamic_bypass_entry 
or dynamic_timeout. When you finish, enter your end- of -file string. 



125 



Blue Coat ProxySG Configuration and Management Guide 



Section I: Using a Bypass List 



Example 

SGOS# (config) inline bypass-list local eof 

max_dynamic_bypass_entry 20000 
server_bypass_threshold 30 
dynamic_timeout 100 eof 
ok 



Using Policy to Configure Dynamic Bypass Lists 

Dynamic bypass, available through policy (VPM or CPL), can automatically compile a list of 
requested URLs that return various kinds of errors. The policy-based bypass list is maintained in the 
Forward Policy file or Local Policy file. 



Note: Because a bypass list bypasses Blue Coat policy, bypass lists should be used sparingly 

only for specific situations. 



Dynamic bypass keeps its own (dynamic) list of which connections to bypass, where connections are 
identified by both source and destination rather than just destination. Dynamic bypass can be based 
on any combination of policy triggers. In addition, some global settings in HTTP configuration can be 
used to selectively enable dynamic bypass based on specific HTTP response codes. Once an entry 
exists in the dynamic bypass table for a specific source/ destination IP pair, all connections from that 
source IP to that destination IP are bypassed in the same way as connections that match against the 
static bypass lists. 

With dynamic bypass, the ProxySG adds dynamic bypass entries containing the specific 
source/ destination IP pair for sites that have returned an error to the appliance's local bypass list. For 
a configured period of time, further requests for the error-causing URLs are sent immediately to the 
origin content server (OCS), saving the ProxySG processing time. The amount of time a dynamic 
bypass entry stays in the list and the types of errors that cause the ProxySG to add a site to the list, as 
well as several other settings, are configurable from the CLI. 

Once the dynamic bypass timeout for a URL has ended, the ProxySG removes the URL from the 
bypass list. On the next client request for the URL, the ProxySG attempts to contact the OCS. If the 
OCS still returns an error, the URL is once again added to the local bypass list for the configured 
dynamic bypass timeout. If the URL does not return an error, the request is handled in the normal 
manner. 

Limitations 

□ Dynamic bypass applies to transparent proxy connections only. 

□ Dynamic bypass entries are lost when the ProxySG is restarted or the static bypass file is 
reinstalled. 

□ No filtering checks are performed on client requests that match entries in the dynamic bypass list. 

□ Requests to sites that are put into the dynamic bypass list bypass future policy evaluation. If a site 
that requires forwarding policy to reach its destination is populated into the bypass list, the site 
might be inaccessible. 



126 



Chapter 4: Configuring the System 



Section I: Using a Bypass List 

□ Sites requiring that client accesses always be subjected to ProxySG filtering considerations must 
either use the appliance in explicit proxy mode or leave dynamic bypass functionality disabled. 

Configuring Dynamic Bypass 

Dynamic bypass is disabled by default. Enabling and fine-tuning dynamic bypass is a two-step 

process: 

□ Edit or create a local bypass list, adding the desired dynamic bypass timeout and threshold 
parameters. 

□ Use the CLI to enable dynamic bypass and set the types of errors that cause dynamic bypass to 
add an entry to the bypass list. 

Adding Dynamic Bypass Parameters to the Local Bypass List 

The first step in configuring dynamic bypass is to edit the local bypass list to set the 

server_bypass_threshold, max_dynamic_bypass_entry , or dynamic_timeout values. 



Note: This step is optional because the ProxySG uses default configurations if you do not 

specify them in the local bypass list. Use the default values unless you have specific 
reasons for changing them. Contact Blue Coat Technical Support for detailed advice on 
customizing these settings. 



□ The server_bypass_threshold value defines the maximum number of entries in the 
dynamically generated portion of the local bypass list before the ProxySG consolidates 
client-server pair entries into a single server entry. The range is 1 to 256. The default is 16. When a 
consolidation occurs, the lifetime of the consolidated entry is set to the value of 

dynami c_t imeout . 

□ The max_dynamic_bypass_entry defines the maximum number of total dynamic bypass entries. 
The range is 1 to 50,000. The default value is 16,000. When the number of entries exceeds the 
max_dynamic_bypass_entry value, the oldest entries are removed to make way for new entries. 

□ The dynamic_timeout value defines the number of minutes a dynamic bypass entry can remain 
unreferenced before it is deleted from the bypass list. The range is 1 to 6000. The default value is 
60. 

Enabling Dynamic Bypass and Specifying Triggers 

Enabling dynamic bypass and specifying the types of errors that causes a URL to be added to the local 
bypass list are done with the CLI. 

To Enable Dynamic Bypass and Trigger Events through the CLI 

At the (config) command prompt, enter the following commands: 

SGOS# (config) dynamic -bypass enable 

SGOS# (config) dynamic -bypass trigger trigger_event 

where trigger_event can be any item in listed in Table 4.1, below. 
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Enabling dynamic bypass causes the following warning to appear: 

WARNING : 

Requests to sites that are put into the dynamic bypass list will bypass 
future policy evaluation. This could result in subversion of on-box policy. 
The use of dynamic bypass is cautioned. 

Table 4.1 : Values for the Dynamic-Bypass Trigger Event 



Event 


Description 


all 


Enables all dynamic bypass triggers. 


non-http 


Enables dynamic bypass for non-HTTP responses. 


connect-error 


Enables dynamic bypass for any connection failure to the origin content server, including 
timeouts. 


receive-error 


Enables dynamic bypass for when a TCP connection to an origin content server succeeds, 
but the cache does not receive an HTTP response. 


400 


Enables dynamic bypass for HTTP 400 responses. 


401 


Enables dynamic bypass for HTTP 401 responses. 


403 


Enables dynamic bypass for HTTP 403 responses. 


405 


Enables dynamic bypass for HTTP 405 responses. 


406 


Enables dynamic bypass for HTTP 406 responses. 


500 


Enables dynamic bypass for HTTP 500 responses. 


502 


Enables dynamic bypass for HTTP 502 responses. 


503 


Enables dynamic bypass for HTTP 503 responses. 


504 


Enables dynamic bypass for HTTP 504 responses. 



Example 

For instance, the following command will enable connection error events: 

SGOS# (config) dynamic -bypass trigger connect-error 

Bypassing Connection and Receiving Errors 

In addition to HTTP code triggers, you can configure the ProxySG to trigger dynamic bypass for 
connection and receiving errors. 

If connect -error is enabled, any connection failure to the origin content server (OCS), including 
timeouts, inserts the OCS destination IP address into the dynamic bypass list. In this instance, the 
ProxySG bypasses any connection attempts from the client to this IP address. By default, the timeout 
duration is 20 seconds, and the retry count is 3. These parameters are not configurable. Both the 
timeout duration and the retry attempt, whichever occurs first, triggers connect -error. 
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If receive-error is enabled, when the cache does not receive an HTTP response on a successful TCP 
connection to the OCS, the OCS destination IP address is inserted into the dynamic bypass list. In this 
instance, the appliance bypasses any attempts from the client to this IP address. Server timeouts can 
also trigger receive-error. The default timeout value is 180 seconds, which can be changed (see 
"Configuring HTTP Timeout” on page 79). 

Disabling Dynamic Bypass Triggers 

Disabling one or more specific dynamic bypass triggers is an easy way to customize which errors 
cause a dynamic bypass entry to be created. For example, if you want all error events except 401 
responses to create a dynamic bypass entry, you can enable all triggers and then disable only the 
401-event trigger. 

To Disable One or More Dynamic Bypass Triggers through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) dynamic -bypass no trigger event 

where event can be any item listed above in Table 4.1. 

To Clear the Dynamic Bypass List through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) dynamic -bypass clear 

To Disable Dynamic Bypass through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) dynamic -bypass disable 

Viewing the Dynamic Bypass List 

You can view the dynamic bypass list several ways: 

To Display the Dynamic Bypass List through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) show bypass-list 

To Display the Dynamic Bypass List through the Management Console 

In a Web browser, enter the following URL: 

https : / / ip_address_of_Prox.ySG: 8082/TCP/IP-bypass 

To View the Current Dynamic Bypass Configuration through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) show dynamic -bypass 
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To Disable Dynamic Bypass through the CLI 

At the (config) command prompt, enter the following command: 
SGOS# (config) dynamic -bypass disable 
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Section J: Installing WCCP Settings 



The ProxySG can be configured to participate in a WCCP (Web Cache Control Protocol) scheme, 

where a WCCP-capable router collaborates with a set of WCCP-configured ProxySG Appliances to 

service requests. 

Before you can install the WCCP configurations, you must create a WCCP configuration file for the 

ProxySG. The ProxySG does not ship with a default WCCP configuration file. 

You can install the WCCP settings several ways: 

□ Using the ProxySG Text Editor, which allows you to enter settings (or copy and paste the contents 
of an already-created file) directly onto the appliance. 

□ Creating a local file on your local system; the ProxySG can browse to the file and install it. 

□ Using a remote URL, where you place an already-created file on an FTP or HTTP server to be 
downloaded to the ProxySG. 

□ Using the CLI inline weep - settings command, which allows you to paste the WCCP settings 
into the CLI. 

□ Using the CLI weep command, which requires that you place an already-created file on an FTP or 
HTTP server and enter the URL into the CLI. 

For more information about WCCP, see Appendix C: "Using WCCP" on page 1087. 

To Install WCCP Settings through the Management Console 

1. Select Configuration>Network>Advanced>WCCP. 

The WCCP tab displays. 



Bypass List WCCP 

p Install WCCP Settings 

Install WCCP Settings from: 



VIPs 



Failover 



Remote URL v 



Install 



- View WCCP Settings 

[ WCCP Settings ~] View the current WCCP Settings 
[ Source ] View source for the current WCCP Settings 



Figure 4-25: Network Advanced WCCP Tab 

2. From the drop-down list, select the method used to install the WCCP settings; click Install. 

• Remote URL: 

Enter the fully-qualified URL, including the filename, where the WCCP file is located. To 
view the file before installing it, click View. Click Install. Viewing the installation status that 
displays; click OK. 
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Figure 4-26: Specifying the Remote Location of a WCCP Settings File 
• Local File: 

Click Browse to display the Local File Browse window. Browse for the file on the local system. 
Open it and click Install. When the installation is complete, a results window opens. View the 
results, close the window, and click Close. 





BlueOCoat 

Systems 


Upload and Install File home support 1 documentation log out 





Upload and Install the WCCP Settings 

1. Paste the file path into the box below or choose a file 
by clicking the Browse., button and opening the file. 

2. Click Install to upload and install the new file It can 
take some time for the upload to complete. Your 
browser may be unresponsive during the upload. 

3. Once the installation is completed the results will be 
displayed in a new page. Close the results page once 
you have finished viewing the results. 

File to upload: 

Browse... | 

Install | Close | 

Figure 4-27: Specifying the Local Location of a WCCP Settings File 
• Text Editor: 

The current configuration is displayed in installable list format. You can customize it or delete 
it and create your own. Click Install. When the installation is complete, a results window 
opens. View the results, close the window, and click Close. 
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BlueQCoat 

Systems 



Upload and Install File 



Edit and Install the WCCP Settings 

1 . Edit the c ontents of the currently installe d file in the b ox b elo w. 

2. Click Install to upload and install the new contents. It can take some time for the upload to complete. 
Your browser may be unresponsive during the upload. 

3. Once the installation is completed the results will be displayed in a new page. Close the results page 
once you have finished viewing the results. 




Figure 4-28: 
3. Click Apply. 



Install | Close | 

Creating a WCCP Settings File on the ProxySG 



To Install WCCP Settings through the CLI 

Do one of the following: 

□ To enter WCCP settings directly onto the ProxySG, enter the following commands at the 
(config) command prompt: 

SGOS# (config) inline weep- settings end-of-file_marker 

weep enable 

weep version 2 

service-group 9 

assignment -type hash 

priority 1 

protocol 6 

service- flags destination- ip -hash 
service-flags ports-def ined 
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ports 80 21 1755 554 80 80 80 80 
interface 6 

home-router 10.16.18.2 
forwarding 12 
eof 

The preceding example implements WCCP load-balancing using a redirection hash table 
(assignment - type hash). You can also use the mask assignment method to load balance 
WCCP traffic (assignment - type mask). However, the mask assignment method can only be 
used with the Catalyst 6500 Series switches and Cisco 7600 series routers. Specifically, the 
"Supervisor Engine II with Policy Feature Card 2 (PFC2) and MSFC2, 256-MB memory option” is 
required. 

For more information about the mask assignment method and detailed instructions on 
configuring a WCCP file, see Appendix C: "Using WCCP" on page 1087. 

□ To enter a path to a remote URL where you have placed an already-created static route table, enter 
the following commands at the (config) command prompt: 

SGOS# (config) weep path url 

where url is a fully qualified URL, including the filename, where the configuration file is 
located. 

SGOS# (config) load weep- settings 

SGOS# (config) weep enable 
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Section K: Virtual IP Addresses 

Virtual IP (VIP) addresses are addresses assigned to a system that are recognized by other systems on 
the network. Up to 255 VIPs can be configured on each ProxySG. They have several uses: 

□ Assign multiple identities to a system on the same or different network, partitioning the box in to 
separate logical entities for resource sharing or load sharing. 

□ Create an HTTPS Console to allow multiple, simultaneous, secure connections to the system. 

□ Direct authentication challenges to different realms. 

□ Set up failover among multiple ProxySG s on the same subnet. 



Note: For information on creating an HTTPS Console, see "Creating and Editing Services" on 

page 160; for information on using VIPs with authentication realms, see Chapter 9: 
"Using Authentication Services" on page 339; to use VIPs with failover, see "Configuring 
Failover" on page 137. 



To Create a VIP through the Management Console 
1. Select Configuration>Network>Advanced>VIPs. 

The VIPs tab displays. 

Bypass List | WCCP VIPs | Failover 

r Virtual IPs: 




Figure 4-29: Network Advanced VIPs Tab 

2. Click New. 

The Add VIP dialog displays. 

3. Enter the virtual IP address you want to use. It can be any IP address, except a multicast address. 
(A multicast address is a group address, not an individual IP address.) 
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Note: You cannot create a VIP address that is the IP address used by the origin content server. 

You must assign a different address on the ProxySG, and use DNS or forwarding to point 
to the origin content server's real IP address. 



4. Click OK; click Apply. 

The VIP address can now be used. 

To Create a VIP through the CLI 

At the (config) command prompt, run the virtual IP address command: 

SGOS# (config) virtual address ip_address 
ok 

To Delete a VIP through the CLI 

Note that VIP addresses are deleted silently. If you are using a VIP for a service, the service will no 
longer work once the VIP is deleted. 

SGOS# (config) virtual no address ip_address 
ok 

To Clear All VIP Addresses in the System 

SGOS# (config) virtual clear 
ok 

To View All the VIPs in the System 

SGOS# (config) show virtual 
Virtual IP addresses: 

SGOS# (config) accelerated-pac path 10.25.36.47 

10 . 9 . 36.47 
10 . 25 . 36.48 

10 . 25 . 36.47 
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Section L: Configuring Failover 

Using IP address failover, you can create a redundant network for any explicit proxy configuration. If 
you require transparent proxy configuration, you can create software bridges to use failover. For 
information on creating software bridges, see "About Bridging" on page 91. 



Note: If you use the Pass-Through adapter for transparent proxy, you must create a software 

bridge rather than configuring failover. For information on using the Pass-Through 
adapter, see "About the Pass-Through Adapter" on page 91. 



Using a pool of IP addresses to provide redundancy and load balancing. Blue Coat migrates these IP 
addresses among a group of machines. 

This section discusses: 

□ "About Failover" 

□ "Configuring Failover" 

□ "Viewing Statistics" 

About Failover 

Failover allows a second machine to take over if a first machine fails, providing redundancy to the 
network through a master/ slave relationship. In normal operations, the master (the machine whose IP 
address matches the group name) owns the address. The master sends keepalive messages 
(advertisements) to the slaves. If the slaves do not receive advertisements at the specified interval, the 
slave with the highest configured priority takes over for the master. When the master comes back 
online, the master takes over from the slave again. 

The Blue Coat failover implementation resembles the Virtual Router Redundancy Protocol (VRRP) 
with the following exceptions: 

□ A configurable IP multicast address is the destination of the advertisements. 

□ The advertisements' interval is included in protocol messages and is learned by the slaves. 

□ A virtual router identifier (VRID) is not used. 

□ Virtual MAC addresses are not used. 

□ MD5 is used for authentication at the application level. 

Masters are elected, based on the following factors: 

□ If the failover mechanism is configured for a physical IP address, the machine owning the 
physical address have the highest priority. This is not configurable. 

□ If a machine is configured as a master using a virtual IP address, the master has a priority that is 
higher than the slaves. 

When a slave takes over because the master fails, an event is logged in the event log. No e-mail 
notification is sent. 
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Configuring Failover 

Before you begin, be aware that software bridges must already exist before you can use them to 
configure failover. For information on configuring bridges, see "Adapters” on page 86. 

You also need to decide which machine is the master and which machines are the slaves, and whether 
you want to configure explicit proxy or transparent proxy network. 

When configuring the group, the master and all the systems in the group must have exactly the same 
failover configuration except for priority, which is used to determine the rank of the slave machines. If 
no priority is set, a default priority of 100 is used. If two ProxySG Appliances have equal priority, the 
one with the highest physical address ranks higher. 

To Configure Failover through the Management Console 
1. Go to Configuration>Network>Advanced>Failover. 

The Failover tab displays. 

Bypass List | WCCP j VIPs Failover 

r Failover Groups: 




New 

Figure 4-30: Network Advanced Failover Tab 
2. Click New. 

The Add Failover Group dialog displays. 
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Figure 4-31 : Add Failover Group Dialog 

3. In the Add Failover Group dialog that appears, fill in the fields as appropriate: 

• Create a group using either a new IP address or an existing IP address. If the group has 
already been created, you cannot change the new IP address without deleting the group and 
starting over. 

• The enabled option specifies whether this group is active or inactive. Select enabled to enable 
the failover group. 

• Multicast address refers to a Class D IP address that is used for multicast. It is not a virtual IP 
address. 



Note: Class D IP addresses are reserved for multicast. A Class D IP address has a first bit 

value of 1, second bit value of 1, third bit value of 1, and fourth bit value of 0. The 
other 28 bits identify the group of computers that receive the multicast message. 



• Relative Priority refers to a range from 1-255 that is assigned to systems in the group. 255 is 
reserved for the system whose failover group ID equals the real IP address. 

• (Optional) Master identifies the system with the highest priority. 

• (Optional) Advertisement Interval refers to the length of time between advertisements sent by 
the group master. The default is 40 seconds. Once the group master has failed, the slave with 
the highest priority takes over (after approximately three times the interval value). The 
failover time of the group can be controlled by setting this value. 

• (Optional, but recommended) Group Secret refers to a password shared only with the group. 

4. Click OK; click Apply. 
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To Configure Failover through the CLI 



1. At the (config) command prompt, enter the following commands: 
SGOS# (config) failover 

SGOS# (config failover) create group_address 



The IP address does not have to exist. 



SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 



failover) edit 
failover group_ 
failover group_ 
failover group_ 
failover group_ 
failover group_ 



group_address 

address) multicast-address 

address ) master 

address ) priority number 

address ) interval seconds 

address ) secret secret 



multicast address 



-or- 



SG0S# (config failover group_address ) 
SGOS# (config failover group_address) 



encrypted- secret encrypted_secret 
enable 



where: 



group_address 


Refers to the IP address or VIP address that is monitored by this group. 
Once the group has been named, you cannot change the name. To 
change the name, you must delete the group and start over. 


multicast -address 
multicast_address 


Refers to a multicast address where the master sends the keepalives 
(advertisements) to the slave systems. 


master 


(Optional) Identifies the system to be used as the master. 


no 


Negates these settings: multicast-address, priority, interval, secret, and 
master. 


priority number 


(Optional) Refers to the rank of slave systems. The range is from 1 to 
254. (The master system, the one whose IP address matches the group 
address, gets 255.) Output of show config and show failover 
might differ when the master system is also the holder of the physical 
IP address. 


interval seconds 


(Optional) Refers to the time between advertisements from the master 
to the multicast address. The default is 40 seconds. Entering no 
interval resets the interval to the default time of 40 seconds. 


secret secret 
-or- 

encrypted- secret 
encrypted_secret 


(Optional but recommended) Refers to a password shared only with 
the group. You can create a secret, which then is hashed, or you can 
provide an encrypted secret. 


enable | disable 


Enables or disables failover on the ProxySG. 



2. (Optional) View the results. 

SGOS# (config) show failover configuration group_address 

Failover Config 

Group Address: 10.25.36.47 

Multicast Address : 224.1.2.3 

Local Address : 10.9.17.159 
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Secret 



: none 



Advertisement Interval: 40 



Priority 
Current State 
Flags 



100 

DISABLED 
V M 



Three flags exist, set as you configure the group. 

V — Specifies the group name is a virtual IP address. 

R — Specifies the group name is a physical IP address 

M — Specifies this machine can be configured to be the master if it is available 
3. (Optional) You can view Failover Group Statistics 

These are all integers/ counters that count various events. 

SGOS# (config) show failover statistics 

Failover Statistics 

Advertisements Received : 0 

Advertisements Sent : 194 

States Changes : 2 

Bad Version : 0 

Bad Packet : 0 

Bad Checksum : 0 

Packet Too Short : 0 

Bad Packet Header : 0 

Invalid Group : 0 



Viewing Statistics 



To view statistics on failover, see "Failover Statistics" on page 1018 
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Section M: Configuring the ProxySG as a Session Monitor 

You can configure the ProxySG to monitor RADIUS accounting messages and to maintain a session 
table based on the information in these messages. The session table can then be used for logging or 
authentication. 

You can also, optionally, configure multiple ProxySG appliances to act as a session monitor cluster. The 
session table is then replicated to all members of the cluster. 

Once configured and enabled, the ProxySG session monitor maintains a session table that records 
which sessions are currently active and the user identity for each session. 

Configuring the Session Monitor 

Three steps are required to configure the session monitor: 

□ Configure the RADIUS accounting protocol parameters for the session monitor. 

□ (Optional) Configure the session monitor cluster. 

□ Configure the session monitor parameters. 

Configuring the RADIUS Accounting Protocol Parameters 

The configuration commands to create the RADIUS accounting protocol parameters can only be done 
through the CLI. If you are using session-monitor clustering, the commands must be done on each 
system in an already-existing failover group. (For information on configuring a failover group, see 
"Section L: Configuring Failover" on page 137.) 

To Configure the RADIUS Accounting Protocol Parameters 

At the (config) prompt, enter the following commands: 

SGOS# (config) session-monitor 

SGOS# (config session-monitor) radius acct-listen-port port_number 
SGOS# (config session-monitor) radius authentication {enable | disable} 

SGOS# (config session-monitor) radius encrypted- shared- secret 

encrypt ed_secret 

SGOS# (config session-monitor) radius no encrypted-shared-secret 
SGOS# (config session-monitor) radius response {enable | disable} 

SGOS# (config session-monitor) radius shared-secret plaintext_secret 

where 



Command 


Option 


Description 


radius 

acct-listen-port 


port number 


The port number where the ProxySG 
listens for accounting messages 


radius authentication 


enable | disable 


Enable or disable (the default) the 
authentication of RADIUS messages 
using the shared secret. Note that the 
shared secret must be configured before 
authentication is enabled. 
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Command 


Option 


Description 


radius 

encrypted- shared- 
secret 


encrypted shared 
secret 


Specify the shared secret (in encrypted 
form) used for RADIUS protocol 
authentication. The secret is decrypted 
using the configuration-passwords-key. 


radius no 
shared- secret 




Clears the shared secret used for 
RADIUS protocol authentication. 


radius response 


enable | disable 


Enable (the default) or disable 
generation of RADIUS responses. 


radius shared- secret 


plaintext_secret 


Specify the shared secret used for 
RAIDUS protocol in plaintext. 



Configuring a Session Monitor Cluster 

Configuring a session monitor cluster is optional. When a session monitor cluster is enabled, the 
session table is replicated to all members of the cluster. The cluster members are the ProxySG 
Appliances that are configured as part of the failover group referenced in the session monitor cluster 
configuration. The failover group must be configured before the session monitor cluster. (For 
information on configuring a failover group, see "Section L: Configuring Failover" on page 137.) 

If you want the session table to be replicated to all the members of a failover group, you can use the 
following commands. 



Note: When using a session monitor cluster, the RADIUS client must be configured to send the 

RADIUS accounting messages to the failover group's virtual IP address. 



Proxy traffic can be routed to any of the machines in the cluster. 



Note: Each member of the failover group must configured with the cluster commands to 

maintain the session table for RADIUS accounting messages. 



To Configure Session Monitor Cluster Parameters 



At the (config) prompt, enter the following commands: 



SGOS# (config) session-monitor 

SGOS# (config session-monitor) 
SGOS# (config session-monitor) 
SGOS# (config session-monitor) 
SGOS# (config session-monitor) 
SGOS# (config session-monitor) 



cluster 

cluster 

cluster 

cluster 

cluster 



{enable | disable} 
group-address IP_address 
port port_number 
grace-period seconds 
synchronization-delay seconds 
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where 



Command 


Option 


Description 


cluster 


enable | 
disable 


Enable or disable (the default) clustering on 
a failover group. The group address must be 
set before the cluster can be enabled. 


cluster group-address 
| no group -address 


IP address 


Set or clear (the default) the failover group 
IP address. This must be an existing failover 
group address. 


cluster port 


port number 


Set the TCP/IP port for the session 
replication control. The default is 55555. 


cluster 

synchronization- delay 


seconds 


Set the maximum time to wait for session 
table synchronization. The default is zero; 
the range is from 0 to 2 A 31 -1 seconds. 
During this time evaluation of 
$ (session. username) is delayed, so 
proxy traffic might also be delayed. 


cluster grace-period 


seconds 


Set the time to keep session transactions in 
memory while waiting for slave logins. This 
can be set to allow session table 
synchronization to occur after the 
synchronization-delay has expired. The 
default is 30 seconds; the range is 0 to 2 A 31-1 
seconds. 



Configuring the Session Monitor 

The session monitor commands set up session monitoring behavior. If using session-monitor 
clustering, these commands must be done on all ProxySG systems in the failover group. 

To Configure the Session Monitor 

1. At the (config) prompt, enter the following commands: 

SGOS# (config) session-monitor 

SGOS# (config session-monitor) disable | enable 
SGOS# (config session-monitor) max-entries integer 
SGOS# (config session-monitor) timeout minutes 

where 



Command 


Option 


Description 


enable | disable 




Enable or disable (the default) session monitoring 


max entries 


integer 


The maximum number of entries in the session table. 
The default is 500,000; the range is from 1 to 2,000,000. If 
the table reaches the maximum, additional START 
messages are ignored. 
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Command 


Option 


Description 


timeout 


minutes 


The amount of time before a session table entry 
assumes a STOP message has been sent. The default is 
120 minutes; the range is from 0 to 65535 minutes. Zero 
indicates no timeout. 



2. (Optional) To view the session-monitor configuration, you can either use the session-monitor 
view command or the config show session-monitor command. 

SGOS# (config) show session-monitor 

General : 

Status: enabled 

Entry timeout: 120 minutes 

Maximum entries: 500000 

Cluster support : enabled 

Cluster port: 55555 

Cluster group address: 10.9.17.159 

Synchronization delay: 0 

Synchronization grace period: 30 

Accounting protocol : radius 

Radius accounting: 

Listen ports : 

Accounting: 1813 
Responses : Enabled 
Authentication: Enabled 
Shared secret: ************ 

Creating the CPL 

Be aware that the examples below are just part of a comprehensive authentication policy. By 
themselves, they are not adequate. 



Note: Refer to the Blue Coat ProxySG Content Policy Language Guide for details about CPL and 

how transactions trigger the evaluation of policy file layers. 



□ The ProxySG is using the session table maintained by the session monitor for authentication. 

<proxy> 

allow authenticate (session) 

where session is a Policy Substitution realm that uses $ (session. username) in building 
the username. (For information on creating a Policy Substitution realm, see "Section K: Policy 
Substitution Realm" on page 453.) 
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Limitations 

□ The session table is kept in memory. If the system goes down, the contents of the session table are 
lost. However, if the system is a member of a failover cluster, the current contents of the session 
table can be obtained from another machine in the cluster. The only situation in which the session 
table is entirely lost is if all machines in the cluster go down at the same time. 

□ The session table is stored entirely in memory. The amount of memory needed is roughly 40MB 
for 500,000 users. 

□ The session replication protocol replicates session information only; configuration information is 
not exchanged. That means that each ProxySG must be properly configured for session 
monitoring. 

□ The session replication protocol is not secured. The failover group should be on a physically 
secure network to communicate with each other. 

□ The session monitor requires sufficient memory and at least lOOMb-per-second network links 
among the cluster to manage large numbers of active sessions. 

□ The username in the session table is obtained from the Calling-Station-ID attribute in the RADIUS 
accounting message and can be a maximum of 19 bytes. 
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Section N: TCP/IP Configuration 

Use the TCP/IP configuration options to enhance the performance and security of the ProxySG. 

Except for IP Forwarding (see "Understanding IP Forwarding" on page 261), these commands are only 

available through the CLI. 

□ RFC-1323: Enabling RFC-1323 support enhances the high-bandwidth and long-delay operation of 
the ProxySG over very high-speed paths, ideal for satellite environments. 

□ TCP NewReno: Enabling TCP NewReno support improves the fast recovery of the ProxySG. 

□ ICMP Broadcast Echo: Disabling the response to these messages can limit security risks and 
prevent an attacker from creating a distributed denial of service (DDoS) to legitimate traffic. 

□ ICMP Timestamp Echo: Disabling the response to these messages can prevent an attacker from 
being able to reverse engineer some details of your network infrastructure. 

□ TCP Window Size: configures the amount of unacknowledged TCP data that the ProxySG can 
receive before sending an acknowledgement. 

□ PMTU Discovery: Enabling PMTU Discovery prevents packets from being unable to reach their 
destination because they are too large. 

To view the TCP/IP configuration, see "Viewing the TCP/IP Configuration" on page 150. 

This section discusses 



□ 


"RFC-1323" 


□ 


"TCP NewReno" 


□ 


"ICMP Broadcast Echo Support” 


□ 


"ICMP Timestamp Echo Support" 


□ 


"TCP Window Size” 


□ 


"PMTU Discovery" 


□ 


"Tep xj me Wait” 


□ 


"Viewing the TCP/IP Configuration" 


RFC-1 


323 



The RFC-1323 TCP/IP option enables the ProxySG to use a set of extensions to TCP designed to 
provide efficient operation over large bandwidth-delay-product paths and reliable operation over 
very high-speed paths, including satellite environments. RFC-1323 support can only be configured 
through the CLI, and is enabled by default. 

To Enable or Disable RFC- 1323 Support through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) tcp-ip rfc-1323 {enable | disable} 
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TCP NewReno 

NewReno is a modification of the Reno algorithm. TCP NewReno improves TCP performance during 
fast retransmit and fast recovery when multiple packets are dropped from a single window of data. 
TCP NewReno support is disabled by default. 

To Enable or Disable TCP NewReno Support through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) tcp-ip tcp-newreno {enable | disable} 

ICMP Broadcast Echo Support 

Disabling the ICMP broadcast echo command can prevent the ProxySG from participating in a Smurf 
Attack. A Smurf attack is a type of Denial-of- Service (DoS) attack, where the attacker sends an ICMP 
echo request packet to an IP broadcast address. This is the same type of packet sent in the ping 
command, but the destination IP is broadcast instead of unicast. If all the hosts on the network send 
echo reply packets to the ICMP echo request packets that were sent to the broadcast address, the 
network is jammed with ICMP echo reply packets, making the network unusable. By disabling ICMP 
broadcast echo response, the ProxySG does not participate in the Smurf Attack. 

This setting is disabled by default. 

To Enable or Disable ICMP Broadcast Echo Support through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) tcp-ip icmp-bcast-echo {enable | disable} 

For more information on preventing DDoS attacks, see "Attack Detection" on page 115. 

ICMP Timestamp Echo Support 

By disabling the ICMP timestamp echo commands, you can prevent an attacker from being able to 
reverse engineer some details of your network infrastructure. 

For example, disabling the ICMP timestamp echo commands prevents an attack that occurs when the 
ProxySG responds to an ICMP timestamp request by accurately determining the target's clock state, 
allowing an attacker to more effectively attack certain time-based pseudo-random number generators 
(PRNGs) and the authentication systems on which they rely. 

This setting is disabled by default. 

To Enable or Disable ICMP Timestamp Echo Support through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) tcp-ip icmp-timestamp-echo {enable | disable} 

TCP Window Size 

Adjusting the TCP window-size regulates the amount of unacknowledged data that the ProxySG 
receives before sending an acknowledgement. 
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To Configure the TCP Window Size through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) tcp-ip window-size window_size 

where window_size indicates the number of bytes allowed before acknowledgement (the 
value must be between 8192 and 4194304). 

PMTU Discovery 

PMTU (Path Maximum Transmission Unit) is a mechanism designed to discover the largest packet 
size sent that is not fragmented anywhere along the path between two communicating Proxy SG 
Appliances that are not directly attached to the same link. A ProxySG doing PMTU sets the 
Do-Not-Fragment bit in the IP header when transmitting packets. If fragmentation becomes 
necessary before the packets arrive at the second ProxySG, a router along the path discards the 
packets and returns an ICMP Host Unreachable error message, with the error condition of 
Needs -Fragmentation, to the original ProxySG. The first ProxySG then reduces the PMTU size and 
re-transmits the transmissions. 

The discovery period temporarily ends when the ProxySG's estimate of the PMTU is low enough that 
its packets can be delivered without fragmentation or when the ProxySG stops setting the 
Do-Not-Fragment bit. Five minutes later (this value is configurable), rediscovery is used to see if the 
transmittable packet size has changed. 

Following discovery and rediscovery, the size of the packets that are transferred between the two 
communicating nodes dynamically adjust to a size allowable by the path, which might contain 
multiple segments of various types of physical networks. 

PMTU is disabled by default. 

A ProxySG that is not running PMTU might send packets larger than that allowed by the path, 
resulting in packet fragmentation at intermediate routers. Packet fragmentation affects performance 
and can cause packet discards in routers that are temporarily overtaxed. 

To Configure PMTU Discovery through the CLI 



Note: PMTU discovery can only be configured through the CLI. It is not available through the 

Management Console. 



At the (config) command prompt, enter the following commands: 



SGOS# (config) 
SGOS# (config) 
SGOS# (config) 



tcp-ip 

tcp-ip 

tcp-ip 



pmtu-discovery 

pmtu-discovery 

pmtu-discovery 



enable | disable 
expire-period seconds 
probe -interval seconds 



where 



tcp-ip 


enable | disable 


Allows you to enable PMTU discovery. The 


pmtu-discovery 




default is disabled. 
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expire -period 


Determines the time, in seconds, when PMTU 




seconds 


rediscovery takes place after receiving the 
ICMP Host Unreachable - Needs 






Fragmentation error message. The default 
is 600 seconds. 



probe- interval seconds Determines the time, in seconds, when the 

next PMTU rediscovery takes place following 
a previous consecutive successful expansion 
of the PMTU value. The default is 120 
seconds. 

TCP Time Wait 

When a TCP connection is closed (such as a user entering "quit" for an FTP session), the TCP 
connection remains in the TIME_WAIT state for twice the Maximum Segment Lifetime (MSL) before 
completely removing the connection control block. 

The TIME_WAIT state allows an end point (one end of the connection) to remove remnant packets 
from the old connection, eliminating the situation where packets from a previous connection are 
accepted as valid packets in a new connection. 

The MSL defines how long a packet can remain in transit in the network. The value of MSL is not 
standardized; the default value is assigned according to the specific implementation. 

To change the MSL value, enter the following commands at the (config) command prompt: 

SGOS# (config) tcp-ip tcp-2msl seconds 

where seconds is the length of time you chose for the 2MSL value. 

Viewing the TCP/IP Configuration 

To view the TCP/IP configuration: 



SGOS# (config) show tcp-ip 



RFC- 1323 support: 


enabled 


TCP Newreno support : 


disabled 


IP forwarding: 


disabled 


ICMP beast echo response: 


disabled 


ICMP timestamp echo response: 


disabled 


Path MTU Discovery: 


enabled 


PMTU expiration period: 


600 seconds 


PMTU probe interval : 


120 seconds 


TCP 2MSL timeout 


120 seconds 


TCP window size: 


65535 bytes 
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This chapter describes port services that are configurable on the ProxySG. These services run on the 
ProxySG, and include Management Consoles such as HTTPS, HTTP, SSH, and Telnet Consoles, and 
application proxies such as Instant Messenger (IM), SOCKS, FTP, MMS, and RTSP, HTTP and HTTPS. 

Other proxy services, like ICAP and Websense, are remote to the ProxySG and are discussed in 
Chapter 11: "External Services" on page 511. 

This chapter discusses 

□ "Managing Multiple Management Consoles" 

□ "Creating and Editing Services" 

This chapter does not discuss configuration of some of the port services that are created or enabled 
here. The following are discussed in Chapter 6: "Configuring Proxies" on page 181: 

O FTP Proxy 

□ HTTP Proxy 

□ SOCKS Proxy 

□ Shell Proxies (Telnet) 

□ SSL Proxy 
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Section A: Managing Multiple Management Consoles 

The ProxySG ships with a number of already existing consoles designed to manage the system and 
communication with the system: 

□ HTTP and HTTPS Consoles: These consoles are designed to allow you access to the ProxySG. The 
HTTPS Console is created and enabled; the HTTP Console is created by default but not enabled 
because it is less secure than HTTPS. 

□ SSH Console: This console is created and enabled by default, allowing you access to the ProxySG 
through the CLI with your SSH service. 

□ Telnet Console: This console is created but is disabled by default because of security concerns. You 
must enable the service before you can access the ProxySG through a Telnet client (not 
recommended) . 

Managing the HTTPS Console (Secure Console) 

The HTTPS Console provides secure access to the Management Console through the HTTPS protocol. 

You can create multiple management HTTPS consoles, allowing you to simultaneously access the 
Management Console using any IP address belonging to the box as well as any of the ProxySG's 
virtual IP (VIP) addresses. The default is HTTPS over port 8082. 

The ProxySG ships with an HTTPS Console already created and enabled. You do not need to create 
other HTTPS Consoles unless you need them for other purposes. 

An HTTPS Console and an HTTPS Reverse Proxy are not the same. The HTTPS Console is for 
accessing the ProxySG. An HTTPS Reverse Proxy allows secure access to other systems. 



Note: Another difference between the HTTPS Console and an HTTPS Reverse Proxy is that an 

SSL proxy license is required for an HTTPS Reverse Proxy. If the ProxySG has no valid 
license for the SSL proxy, you get an exception page when you attempt to connect to the 
HTTPS Reverse Proxy. 

You can set up and use the HTTPS Secure Console without an SSL proxy license. 

For information on licensing, see Chapter 2: "Licensing" on page 47. 



Creating a new HTTPS Console port requires three steps, discussed in the following sections: 

□ Selecting a keyring (a keypair and a certificate that is stored together) 

□ Selecting an IP address and port on the system that the service will use, including virtual IP 
addresses 

□ Putting the keyring and service together into an HTTPS Console 
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Selecting a Keyring 

The ProxySG ships with a default keyring that can be reused with each HTTPS Reverse Proxy that you 
create. You can also create your own keyrings for other purposes. 

To use the default keyring, accept the default keyring through the Management Console. If using the 
CLI, enter default for the keyring ID when using the services https -console create command. 



Note: When using certificates for the HTTPS Console or for HTTPS termination services that are 

issued by Certificate Signing Authorities that are not well-known, see "Creating 
Self-Signed SSL Certificates" on page 280. 

If you get "host mismatch" errors or if the security certificate is called out as invalid, 
create a different certificate and use it for the HTTPS Console. 



For information on creating a keypair and a certificate to make a keyring, see "Section B: Configuring 
HTTPS Reverse Proxy" on page 270. 

Selecting an IP Address 

You can use any IP address on the ProxySG for the HTTPS Console service, including virtual IP 
addresses. To create a virtual IP address, see "Virtual IP Addresses" on page 135. 

Enabling the HTTPS Console Service 

The final step in editing or creating an HTTPS Console service is to select a port and enable the 
service. 

To Create or Edit an HTTPS Console Port Service through the Management Console 
1. Select Configuration>Services>Service Ports. 
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Seivice Ports 

r Services: 






V 



Figure 5-1 : Service Ports Tab 
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no 


Transparent,... 
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1863 
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no 
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no 
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New | [ Edit ] [ Delete 



2. Do one of the following: 

• To create a new HTTPS Console port service, click New; the Add Service dialog appears. Select 
HTTPS-Console from the Protocol drop-down list. 

• To edit an existing HTTPS Console port service, highlight the HTTPS Console and click Edit; 
the Edit Service dialog appears. 

Continue with the next step. 



Add service 






- Add service — 

Protocol: 

IP: 

Port: 

Keyring: 

SSL Versions: 




( OK ] [ Cancel ] 

Figure 5-2: HTTPS-Console Add Service Dialog 

3. The default IP address value is <AII>. To limit the service to a specific IP address, select the IP 
address from the drop-down list. It must already exist. 

4. Identify the port you want to use for this service. 
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5. In the Keyring drop-down list, select any already created keyring that is on the system. The system 
ships with a default keyring that is reusable for each HTPPS service. 



Note: The configuration-passwords-key keyring that shipped with the ProxySG does not 

contain a certificate and cannot be used for HTTPS Consoles. 



6. (Optional) In the SSL Versions drop-down list, select the version to use for this service. The default 
is SSL v2 / v3 and TLS vl . 

7. Click OK; click Apply. 

Note: For information on creating keyrings and client certification lists, see "Section B: 

Configuring HTTPS Reverse Proxy" on page 270. 



To Create Another HTTPS Console Port Service through the CLI 

1. At the (config) command prompt, enter the following commands: 

SGOS# (config) services 

SGOS# (config services) https-console 

SGOS# (config services https-console) create [ ip_address :] port [ keyring_id ] 

If you do not specify a keyring, the default is used. 

SGOS# (config services https-console) attribute cipher-suite ip_address : port 

2. (Optional) View the results: 

SGOS# (config services https-console) view 

Port: 8082 IP: 0.0. 0.0 Type: https-console 

Keyring: default 

Properties: explicit, enabled 

Cipher suite : 

RC4 -MD5 : RC4 - SHA : DES -CBC3 - SHA : DES-CBC3 -MD5 : RC2 -CBC-MD5 : RC4 - 64 -MD5 : DES-CBC-SHA 
: DES -CBC-MD5 : EXP1024 -RC4 -MD5 : EXP1 024 -RC4 - SHA : EXP1024 -RC2 -CBC-MD5 : EXP1 024 -DES 
-CBC- SHA : EXP-RC4 -MD5 : EXP-RC2 -CBC-MD5 : EXP -DES - CBC- SHA : 

+SSLv2 : +SSLv3+LOW : +SSLv2+LOW : +EXPOHTTP 



Note: To create client-certification lists and keyrings, see "Section B: Configuring HTTPS 

Reverse Proxy" on page 270. To set the cipher-suite to the ciphers you want to use, see 
"Changing the Cipher Suites of the SSL Client" on page 293. 



Managing the HTTP Console 

The HTTP Console is meant to allow you to access the ProxySG if you require a less secure 
environment. The default HTTP Console is already configured; you must enable it before it can be 
used. 

You can create and use more than one HTTP Console as long the IP address and the port do not match 
the existing HTTP Console settings. 
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To Create or Edit an HTTP Console Port Service through the Management Console 

1. Select Configuration>Services>Service Ports. 

2. Do one of the following: 

• To create a new HTTP-Console port service, click New; the Add Service dialog appears. Select 
HTTP-Console from the Protocol drop-down list. 

• To edit an existing HTTP-Console port service, highlight the HTTP-Console and click Edit; the 
Edit Service dialog appears. 




Figure 5-3: HTTP-Console Add Service Dialog 
In either case, continue with the next step. 

3. The default IP address value is <AII>. To limit the service to a specific IP address, select the IP 
address from the drop-down list. It must already exist. 

4. Identify the port you want to use for this service. 

5. Click OK; click Apply. 

To Create or Edit an HTTP Console Port Service and Enable It through the CLI 

1. At the (config) command prompt, enter the following commands: 

SGOS# (config) services 

SGOS# (config services) http-console 

SGOS# (config services http-console) create [ip_address :] port 

2. (Optional) View the results: 

SGOS# (config services http-console) view 

Port: 8085 IP: 0.0. 0.0 Type: http-console 

Properties : enabled 

Managing the SSH Console 

The SSH Console is created and enabled by default. Only one SSH Console can exist on the ProxySG. 
If you inadvertently deleted the SSHvl and SSHv2 host keys from the system at the same time, you 
automatically disabled the SSH Console and must enable the SSH Console after you create a host key. 

For information on managing SSH, see "Configuring the SSH Console" on page 67. 
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To Edit an SSH Console Service through the Management Console 

1. Select Configuration>Services>Service Ports. 

2. To edit the existing SSH-Console port service, highlight the SSH-Console and click Edit. 
The Edit Service dialog appears. 




Figure 5-4: SSH-Console Add Service Dialog 

3. The default IP address value is all. To limit the service to a specific IP address, select the IP address 
from the drop-down list. 

4. In the Port field, specify a port number; select Enable. 

5. Click OK; click Apply. 

To Create an SSH Port Service through the CLI 

1. At the (config) command prompt, enter the following commands: 

SGOS# (config) services 

SGOS# (config services) ssh-console 

SGOS# (config services ssh-console) create [ip_address:] port 
SGOS# (config services ssh-console) enable [ip_address:] port 

2. (Optional) View the results: 

SGOS# (config services ssh-console) view 

Port: 22 IP: 0.0. 0.0 Type: ssh-console 

Properties : enabled 

Managing the Telnet Console 

The Telnet Console allows you to connect to and manage the ProxySG using the Telnet protocol. 
Remember that Telnet is an insecure protocol that should not be used in insecure conditions. By 
default, only SSH is created and enabled. 

Blue Coat Systems recommends against using Telnet because of the security hole it creates. 
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Note: If you do enable the Telnet Console, be aware that you cannot use Telnet everywhere in 

the CLI. Some modules, such as SSL, respond with the error message: 

Telnet sessions are not allowed access to ssl commands. 



To Create or Edit a Telnet Console Port Service through the Management Console 

Before you begin, verify that no Telnet service exists on the default telnet port (23). If it does exist, 
delete it and apply the changes before continuing. If you also want a Telnet service, you can re-create 
it later (use a different port). For information on the Telnet service, see' Managing the Telnet Shell 
Proxy Service" on page 177. 

1. Select Configuration>Services>Service Ports. 

2. Do one of the following: 

• To create a new Telnet-Console port service, click New; the Add Service dialog appears. Select 
Telnet-Console from the Protocol drop-down list. 

• To edit an existing Telnet-Console port service, highlight the Telnet-Console and click Edit; the 
Edit Service dialog appears. 

In either case, continue with the next step. 



Add service (X 




OK ) [ Cancel J 

Figure 5-5: Telnet Console Edit Service Dialog 

3. Select Telnet protocol from the drop-down list. 

4. The default IP address value is all. To limit the service to a specific IP address, select the IP address 
from the drop-down list. 

5. In the Port field, specify a port number; 23 is the default. 

Note: To use the Telnet shell proxy and retain the Telnet Console, you must change the port 

number on one of them. Only one service is permitted on a port. For more information on 
the Telnet shell proxy, see "Understanding Telnet Shell Proxies" on page 231. 

6. Select Enabled. 
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7. Click OK; click Apply. 

To Create or Edit a Telnet Port Service through the CLI 

1. At the (conf ig) command prompt, enter the following commands: 

SGOS# (config) services 

SGOS# (config services) telnet-console 

SGOS# (config services telnet-console) create [ip_address :] port 

2. (Optional) View the results. 

SGOS# (config services telnet-console) view 

Port: 23 IP: 0.0. 0.0 Type: telnet-console 

Properties : enabled 
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Section B: Creating and Editing Services 

Proxy services define the ports for which ProxySG will terminate incoming requests. A variety of 
attributes for each service can also be defined. Each service can be applied to all IP addresses or 
limited to a specific address. A number of default services are predefined. Additional services can be 
defined on other ports. 

You can create as many services as you require, keeping in mind that every newly created service uses 
up resources. 



Note: When multiple non-wildcard services are created on a port, all of them must be of the 

same service type (a wildcard service is one that is listening for that port on all IP 
addresses). This means that if you have multiple IP addresses, and you specify IP 
addresses for a port service, you cannot specify a different protocol if you define the same 
port on another IP address. For example, if you define HTTP port 80 on one IP address, 
you can only use the HTTP protocol on port 80 for other IP addresses. 

Also note that wildcard services and non-wildcard services cannot both exist at the same 
time on a given port. 



The following table lists the available ProxySG services, including their attributes and default status. 
The defaults are for a new ProxySG. If you have an upgraded appliance, the settings do not change. 



Table 5.1 : Proxy Port Services 



Proxy Service 


Default Port 


Status 


Configuration Discussed 


DNS 


53 (both transparent and explicit) 


Disabled 


"Managing the DNS Proxy" 


EPMapper 


135 (both transparent and explicit) 


Disabled 


"Managing the Endpoint Mapper 
Proxy" 


FTP 


21 (transparent and explicit 


Disabled 


"Managing the FTP Service" 


HTTP 


80 (transparent and explicit) 
8080 (explicit only) 


Enabled 


"Managing HTTP Services" 


HTTP -Console 


8081 


Disabled 


"Managing the HTTP Console" 


HTTPS Reverse 
Proxy 




Disabled 


"Managing the HTTPS Reverse 
Proxy" 


HTTPS -Console 


8082 


Enabled 


"Managing the HTTPS Console 
(Secure Console)" 


MSN- IM 


1863 (transparent and explicit) and 
6891 (transparent and explicit) 


Disabled 


"Managing Instant Messaging 
Protocols" 


Yahoo- IM 


5050 (transparent and explicit) and 
5101 (transparent and explicit) 


Disabled 


"Managing Instant Messaging 
Protocols" 
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Table 5.1 : Proxy Port Services (Continued) 



Proxy Service 


Default Port 


Status 


Configuration Discussed 


AOL-IM 


5190 (transparent and explicit) 


Disabled 


"Managing Instant Messaging 
Protocols" 


MMS 


1755 (transparent and explicit) 


Disabled 


"Managing Streaming Protocols" 


RTSP 


554 (transparent and explicit) 


Disabled 


"Managing Streaming Protocols" 


SOCKS 


1080 


Disabled 


"Managing SOCKS Services" 


SSH-Console 


22 


Enabled 


"Managing the SSH Console" 


TCP-Tunnel 




Not Created 


"Managing TCP Tunneling Services" 


Telnet -Console 


23 


Not Created 


"Managing the Telnet Console" 


Telnet Shell 
Proxy 


23 


Disabled 


"Managing the Telnet Shell Proxy 
Service" 



Note: If HTTP is configured to be explicit, Internet Explorer version 6.0 users accessing FTP sites 

over HTTP must disable the browser setting Enable folder view for FTP sites. To access this 
attribute in Internet Explorer, select Tools>lnternet Options, click the Advanced tab, deselect 
Enable folder view for FTP sites, and click OK. 



About Service Attributes 

The service attributes define the parameters the ProxySG uses for a particular service. 



Note: For all service types except HTTPS, a specific listener cannot be posted on a port if the 

same port has a wildcard listener of any service type already present. 



The following table describes the attributes; however, depending on the protocol, not all attributes are 
available. 



Table 5.2: Attributes 



Attribute 


Description 


Explicit 


Enables or disables explicit attribute for the port. (Explicit allows connections to a 
ProxySG IP address.) 

Note: If DNS redirection is used to direct traffic to the ProxySG, the explicit flag on 
its services must be enabled, as these connections are routed through DNS to the 
ProxySG's IP address. 


Transparent 


Enables or disables transparent-proxy attribute for port. (This allows connections to 
any IP address other than those belonging to the ProxySG.) 
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Table 5.2: Attributes 



Attribute 


Description 


Authenticate-401 


All transparent and explicit requests received on the port always use transparent 
authentication (cookie or IP, depending on the configuration). This is especially 
useful to force transparent proxy authentication in some proxy-chaining scenarios. 


Send client IP 


Enables or disables sending of client's IP address instead of the ProxySG's IP 
address. For more information, see the section on tracking client IP addresses using 
server-side transparency. 



Note: If you use the CLI to create a service, specify o . o . o . o to define that the service listens on 

all IP addresses; specify the individual IP address to limit the service to one IP address. 



Managing the DNS Proxy 

When a DNS proxy service is enabled, it listens on port 53 for both explicit and transparent DNS 
domain query requests. By default, the service is created but not enabled. 

The DNS does a lookup of the DNS cache to determine if requests can be answered. If yes, the 
ProxySG responds. If not, the DNS forwards the request to the DNS server list configured on the 
ProxySG. (To configure the DNS server list, see Configuration>Network>DNS.) 



Note: The ProxySG is not a DNS server. It does not perform zone transfers, and recursive 

queries are forwarded to other name servers. 



Through policy, you can configure the list of resolved domain names (the resolving name list) the DNS 
uses. The domain name in each query received by the ProxySG is compared against the resolving 
name list. Upon a match, the ProxySG checks the resolving list. If a domain name match is found but 
no IP address was configured for the domain, the ProxySG sends a DNS query response containing its 
own IP address. If a domain name match is found with a corresponding IP address, that IP address is 
returned in a DNS query response. All unmatched queries are sent to the name servers configured on 
the ProxySG. 

To Create or Edit a DNS Proxy Service through the Management Console 

1. Select Configuration>Services>Service Ports. 

2. Click New or Edit; the Add (or Edit) Service dialog appears. 

3. Select DNS from the Protocol drop-down list. 
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Add service 



JSJxJ 



hoo service 



Protocol: 

IP: 

Port: 



[<Aii> 3 

[53 W Enabled 



Attributes: 



W Explicit 

V Transparent 

V S end-client-1 P 



OK | Cancel | 

Figure 5-6: DNS Add Service Dialog 

4. The default IP address value is All. To limit the service to a specific IP address, select the IP address 
from the drop-down list. 

5. In the Port field, 53 displays; you can change it to any unused port. 

6. Select Enabled. 

7. In the Attributes field, select Transparent, Explicit, Send-client-IP (spoofing), or all three. Explicit is the 
default. 



Note: The Send-client-IP attribute allows the ProxySG to pretend to be a client, allowing the 

origin content server to see the client's IP address. If an alternate path exists for traffic 
returning from the Internet to the client, the Send-client-IP attribute does not work. 



8. Click OK; click Apply. 

To Create or Edit a DNS Proxy Service through the CLI 

1. At the (conf ig) command prompt, enter the following commands to set the value returned to the 
client before configuring the DNS service: 

SGOS# (config) services 
SGOS# (config services) dns 

SGOS# (config services dns) create ip_address : port 

2. If you do not need to change the defaults, you have completed the procedure. To change the 
attributes, enter the following command: 

SGOS# (config services dns) attribute {explicit | transparent | 
send-client-ip} {enable | disable} [ip_address :] port 
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where: 



attribute 


explicit | 
transparent | 
send-client-ip enable 
[ip_address:] port 


Give the DNS proxy explicit and transparent 
attributes, and create IP spoofing (where the ProxySG 
pretends to be a client so the OCS can see the client's IP 
address). 

Note: The Send-client-IP attribute allows the ProxySG 
to pretend to be a client, allowing the origin content 
server to see the client's IP address. If an alternate path 
exists for traffic returning from the Internet to the 
client, the Send-client-IP attribute does not work. 


enable 


[ ip_address : ] port 


Enable the new DNS proxy. 



3. (Optional) View the results: 

SGOS# (config services dns) view 

Port: 53 IP: 0.0. 0.0 Type: dns 

Properties: transparent, explicit, enabled 
Port: 54 IP: 0.0. 0.0 Type: dns 

Properties: transparent, enabled 

Creating a Resolving Name List 

You can create the resolving name list that the DNS proxy uses to resolve domain names. This 
procedure can only be done through policy. (For a discussion on using the <dns - Proxy> layer, refer to 
the Blue Coat ProxySG Content Policy Language Guide.) 

Each name resolving list entry contains a domain-name matching pattern. The matching rules are: 

□ test . com matches only test . com and nothing else. 

□ .test.com matches test . com, www. test . com and so on. 

□ matches all domain names. 

An optional IP address can be added, which allows the DNS proxy to return any IP address if the DNS 
request's name matches the domain name suffix string ( domain . name). 

To create a resolving name list, create a policy, using the <DNS-Proxy> layer, that contains text similar 
to the following: 

<DNS-Proxy> 

dns . request . name=www . example . com dns . respond . a (vip) 

-or- 

<DNS-Proxy> 

dns . request . name= . example . com dns . respond . a (vip) 

-or- 

<DNS-Proxy> 

dns . request . name=www . example . com dns . respond . a ( 10 . 1 . 2 . 3 ) 



Note: You can also create a resolving name list using VPM. For more information on using the 

DNS-Proxy layer in VPM, see "Web Content Policy Layer Reference" on page 587. 
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Managing the Endpoint Mapper Proxy 

The Endpoint Mapper proxy accelerates Microsoft RPC traffic (applications that use dynamic port 
numbers) between branch and main offices, automatically creating TCP tunnels to ports where RPC 
services are running. The Endpoint Mapper proxy can be used in both explicit and transparent mode. 



Note: Endpoint Mapper works by intercepting and tunnelling RPC traffic in the branch office 
(branch proxy). The tunneled data is compressed and forwarded to the main office (concentrator 
proxy). The upstream proxy, using SOCKS gateways, decompresses the traffic and forwards it to 
RPC server. (For information on SOCKS compression, see "Understanding SOCKS Compression" 
in Chapter 6, Proxies.) 



By default, the service is created but not enabled. 

To Create or Edit Endpoint Mapper Service through the Management Console 

1. Select Configuration>Services>Service Ports. 

2. Click New or highlight the existing Endpoint Mapper proxy service and click Edit; the Add (or 
Edit) Service dialog appears. 

3. Select EndpointMapper from the Protocol drop-down list. 



Add service 




( OK ] [ Cancel ) 

Figure 5-7: Endpoint Mapper Edit Service Dialog 

4. The default IP address value is All. It cannot be changed. 

5. In the Port field, 135 displays. Port 135 is the standard port for Microsoft RPC traffic. 

6. Select Enabled. 

7. In the Attributes field, select Send-client-IP, if necessary. Explicit and Transparent attributes are not user 
configurable. 
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Note: The Send-client-IP attribute allows the ProxySG to pretend to be a client, allowing the 

origin content server to see the client's IP address. If an alternate path exists for traffic 
returning from the Internet to the client, the Send-client-IP attribute does not work. 



8. Click OK; click Apply. 

To Create or Edit an Endpoint Mapper Proxy Service through the CLI 

1. At the (conf ig) command prompt, enter the following commands to create a new Endpoint 
Mapper proxy service. If you want to edit the existing Endpoint Mapper proxy, skip to step 2.: 

SGOS# (config) services 

SGOS#(config services) epmapper 

SGOS# (config services epmapper) create port 

2. To enable the Endpoint Mapper proxy service or enable the send- cl ient - ip attribute, enter the 
following commands: 

SGOS# (config services epmapper) enable port 

SGOS# (config services epmapper) attribute send-client-ip {enable | disable} 

port 



where: 



attribute 


send-client-ip enable port 


Enable sending the client’s IP address instead of 
the ProxySG’s IP address. 

Note: If an alternate path exists for traffic 
returning from the Internet to the client, the 
Send-client-IP attribute does not work. 


enable 


port 


Enable the new Endpoint Mapper proxy. Port 
135 is the standard port for Microsoft RPC 
traffic. 



3. (Optional) View the results: 

SGOS# (config services epmapper) view 

Port: 135 IP: 0.0. 0.0 Type: epmapper 

Properties: transparent, explicit, disabled 

Managing the FTP Service 

To configure the native FTP proxy, see "Configuring the FTP Proxy" on page 185. 

To Create or Edit an FTP Port Service through the Management Console 

1. Select Configuration>Services>Service Ports. 

2. Click New or Edit; the Add (or Edit) Service dialog appears. 

3. Select FTP from the Protocol drop-down list. 
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Figure 5-8: FTP Edit Service Dialog 

4. The default IP address value is all. To limit the service to a specific IP address, select the IP address 
from the drop-down list. 

5. In the Port field, specify a port number; select the Enabled checkbox. 

6. In the Attributes field, both Explicit and Transparent are selected. You can de-select one of them if 
necessary 

7. Click OK; click Apply. 

To Create an FTP Service through the CLI 

1. At the (config) command prompt, enter the following commands: 

SGOS# (config) services 
SGOS# (config services) ftp 

SGOS# (config services ftp) create [ip_address : ] port 

SGOS# (config services ftp) attribute passive-mode {enable | disable} 

-or- 

SGOS# (config services ftp) attribute {explicit | transparent} {enable | 
disable} [ip_address :] port 

2. (Optional) View the results. 

10.9.17.159 - Blue Coat SG3000# (config services ftp) view 
Port: 21 IP: 0.0. 0.0 Type: ftp 

Properties: transparent, enabled, passive-allowed 
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Managing HTTP Services 

Two HTTP services exist by default and are enabled, one with explicit and transparent attributes on 
port 80 and one with explicit attributes on port 8080. You can change the attributes or create other 
HTTP ports if needed. For example, if you configure SSL proxy functionality, you must use an HTTP 
service to allow the browser to issue HTTP CONNECT requests to the ProxySG for HTTPS content. 
You need to create an HTTP Service if one does not exist already. The ProxySG detects the presence of 
the SSL protocol and enables SSL Proxy functionality for such connections. For more information on 
SSL Proxy functionality, see "Configuring an SSL Proxy" on page 235. 

To Create or Edit an HTTP Port Service through the Management Console 

1. Select Configuration>Services>Service Ports. 

2. Click New or highlight the service and click Edit; the Add (or Edit) Service dialog appears. 

3. Make sure HTTP is selected from the Protocol drop-down list. 



Add service 




I OK | | Cancel I 

Figure 5-9: HTTP Edit Service Dialog 

4. The default IP address value is all. To limit the service to a specific IP address, select the IP address 
from the drop-down list. 

5. In the Port field, specify a port number; be sure Enabled is selected. 

6. In the Attributes field, select all that apply: Explicit, Transparent, Authenticate-401, or Send-client-IP. 

Note: The Send-client-IP attribute allows the ProxySG to pretend to be a client, allowing the 

origin content server to see the client's IP address. If an alternate path exists for traffic 
returning from the Internet to the client, the Send-client-IP attribute does not work. 



7. Click OK; click Apply. 
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To Create an HTTP Service through the CLI 

Two HTTP services exist and are enabled on the ProxySG. If you need to create another at a different 
port in addition to the services already existing on the system, complete the following steps: 

At the (conf ig) command prompt, enter the following commands: 

SGOS# (config) services 
SGOS#(config services) http 

SGOS# (config services http) create [ip_address :] port 

SGOS# (config services http) attribute {authenticate-401 | explicit | 
send-client-ip | transparent} {enable | disable} [ip_address:] port 



Note: The Send-client-IP attribute allows the ProxySG to pretend to be a client, allowing the 

origin content server to see the client's IP address. If an alternate path exists for traffic 
returning from the Internet to the client, the Send-client-IP attribute does not work. 



To view the results: 

SGOS# (config services http) view 

Port: 8080 IP: 0.0. 0.0 Type: http 

Properties: explicit, enabled 

Port: 8 0 IP: 0.0. 0.0 Type: http 

Properties: transparent, explicit, enabled 

Managing the HTTPS Reverse Proxy 

The HTTPS reverse proxy is not configured or enabled by default when the ProxySG ships. You can 
configure and use multiple HTTPS reverse proxies. 



Note: With SGOS version 4.2, the HTTPS service was renamed to HTTPS Reverse Proxy service. 

Nothing else changed. 



To Create an HTTPS Reverse Proxy through the Management Console 

1. Select Configuration>Services>Service Ports. 

2. Click New; the Add Service dialog appears. 

3. Select HTTPS Reverse Proxy from the Protocol drop-down list. 
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Add service 




OK | Cancel | 

Figure 5-10: HTTPS Reverse Proxy Add Service Dialog 

4. To select or add an IP address, do one of the following: 

• To select a local address, specify a real IP address from the IP drop-down list. All is not a 
selection option. 

• To add a non-local IP address, first select the Transparent attribute, then enter a non-local IP 
address that is not bound to the ProxySG. 

5. In the Port field, specify a port number; select Enable. 

6. In the Attributes field, select all that apply: Explicit, Transparent, Send-client-IP, Verity-client, or 

Forward-client-cert. 

• The Send-client-IP attribute lets the ProxySG to pretend to be a client, allowing the origin 
content server to see the client's IP address. 

• The Verity-client attribute requests the client certificate and validates the client certificate 

• The Forward-client-cert attribute, when used with the verify-client attribute, puts the extracted 
client certificate information into a header that is included in the request when it is forwarded 
to the OCS. The name of the header is Client-Cert. The header contains the certificate serial 
number, subject, validity dates and issuer (all as name = value pairs). The actual certificate 
itself is not forwarded. 
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7. In the Keyring drop-down list, select any already-created keyring that is on the system. The system 
ships with a default keyring that can be reused for each HTTPS Reverse Proxy. Keep in mind that 
the default certificate associated with the default keyring is self-signed and might not be trusted 
by all clients. 



Note: The configuration-passwords-key keyring that shipped with the ProxySG does not 

contain a certificate and cannot be used for HTTPS Reverse Proxies. 



8. In the SSL Versions drop-down list, select the version that you want to use for this service. The 
default is SSL v2/v3 and TLS vl. 

9. In the CA-Cert Lists drop-down list, select the list (already created) for the HTTPS Reverse Proxy to 
use. 

10. Click OK; click Apply. 



Note: To create CA certification lists (CCLs) and keyrings, see "Section B: Configuring HTTPS 

Reverse Proxy" on page 270. 



To Create an HTTPS Reverse Proxy through the CLI 



1 . 



At the (config) command prompt, enter the following commands: 



SGOS# (config) services 
SGOS# (config services) 
SGOS# (config services 
SGOS# (config services 
ip_address : port 
-or- 

SGOS# (config services 
ip_address : port 
-or- 



https- reverse -proxy- 

https -reverse -proxy) 
https -reverse -proxy) 

https -reverse -proxy) 



create ip_address -.port keyring 

attribute ccl list name 



attribute cipher-suite 



SGOS# (config services https -reverse -proxy) attribute {forward-client-cert | 

send-client-ip | verify-client} {enable | disable} ip_address : port 

-or- 



SGOS# (config services https -reverse -proxy) attribute ssl-protocol-version 
{ sslv2 I sslv3 I tlsvl I sslv2v3 1 sslv2tlsvl / sslv3tlsvl / sslv2v3tlsvl} 
ip_address : port 



Note: If the ProxySG HTTPS Reverse Proxy is configured to require a client certificate 

(verify-client and forward-client-cert are enabled), information from the client certificate 
is extracted and put into a header that is included in the request when it is forwarded to 
the OCS. 

The Send-client-IP attribute lets the ProxySG to pretend to be a client, allowing the origin 
content server to see the client's IP address. 

The Verify-client attribute requests the client certificate and validates the client certificate. 
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The Forward-client-cert attribute, when used with the verity-client attribute, puts the 
extracted client certificate information into a header that is included in the request when 
it is forwarded to the OCS. The name of the header is Client-Cert. The header contains 
the certificate serial number, subject, validity dates and issuer (all as name= value pairs). 
The actual certificate itself is not forwarded. 



2. (Optional) View the results: 

SGOS# (config services https -reverse -proxy) view 

Port: 1000 IP: 10.9.17.159 Type: https 

Keyring: default 

Properties: explicit, enabled 

SSL Protocol version: SSLv2v3TLSvl 

CA Certificate List: not configured 

Cipher suite : 

RC4 -MD5 : RC4 - SHA : DES -CBC3 - SHA : DES-CBC3 -MD5 : RC2 -CBC-MD5 : RC4 - 64 -MD5 : DES-CBC-SHA 
: DES-CBC-MD5 : EXP1024 -RC4 -MD5 : EXP1 024 -RC4 - SHA : EXP1024 -RC2 -CBC-MD5 : EXP1 024 -DES 
-CBC-SHA:EXP-RC4-MD5 : EXP-RC2 -CBC-MD5 : EXP-DES - CBC- SHA : AES12 8 - SHA : AES2 56 -SHA : + 
SSLv2 : +SSLv 



Managing Instant Messaging Protocols 

Supported instant messaging (IM) services are present by default with the transparent and explicit 
attributes selected and listening on all IP addresses; none of them are enabled. The explicit attribute is 
not user-configurable. 

To Create or Enable an AOL, Yahoo, or MSN Port Service through the Management Console 

1. Select Configuration>Services>Service Ports. 

2. Click New or highlight the service you want and select Edit; the Add (or Edit) Service dialog 
appears. 

3. Select the IM service you want to create or edit from the Protocol drop-down list. 

4. The default port is determined by the protocol: 

• AOL— Port 5190 

• Yahoo — Ports 5050 and 5101 

• MSN— 1863 and 6891 

5. Click OK; click Apply. 

To Manage an Instant Messaging Service through the CLI 

1. At the (config) command prompt, enter the following commands: 

SGOS# (config) services 

SGOS# (config services) aol-im | msn-im | yahoo-im 
SGOS# (config services protocol ) create port 

SGOS# (config services protocol ) attribute send-client-ip {enable | disable} 

port 
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Note: The send-client-IP attribute allows the ProxySG to pretend to be a client, allowing the 

origin content server to see the client's IP address. If an alternate path exists for traffic 
returning from the Internet to the client, the Send-client-IP attribute does not work. 



2. (Optional) View the results: 

SGOS# (config services aol-im) view 

Port: 5190 IP: 0.0. 0.0 Type: aol-im 

Properties: transparent, explicit, enabled 

SGOS# (config services aol-im) exit 

SGOS# (config services) yahoo-im 

SGOS# (config services yahoo-im) view 

Port: 5050 IP: 0.0. 0.0 Type: yahoo-im 

Properties: transparent, explicit, enabled 

Managing Streaming Protocols 

MMS and RTSP services are configured on the system, but are disabled by default. To enable the 
default MMS and RTSP service, follow the steps below. 

To Enable an MMS or RTSP Port Service through the Management Console 

1. Select Configuration>Services>Service Ports. 

2. Click New to create a new MMS or RTSP port service or highlight the existing service and click 
Edit. 

The Add (or Edit) Service dialog appears. 

3. Select MMS or RTSP from the Protocol drop-down list. 

4. The default IP address value is All. To limit the service to a specific IP address, select the IP address 
from the drop-down list. 

5. In the Port field, specify a port number; select Enabled. 

6. In the Attributes field, select the attributes you want the service to have. 

7. Click OK; click Apply. 

To Enable an MMS or PTSP Service through the CLI 

1. At the (config) command prompt, enter the following commands: 

SGOS# (config) services 

SGOS# (config services) {mms | rtsp} 

SGOS# (config services protocol ) create [ip_address :] port 

SGOS# (config services protocol ) attribute {explicit | send-client- ip | 

transparent} {enable | disable} [ip_address:] port 
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Note: The send-client-IP attribute allows the ProxySG to pretend to be a client, allowing the 

origin content server to see the client's IP address. If an alternate path exists for traffic 
returning from the Internet to the client, the Send-client-IP attribute does not work. 



2. (Optional) View the results: 

SGOS# (config services rains) view 
Port: 1755 IP: 0.0. 0.0 

Properties: transparent, explicit, 
SGOS# (config services rams) exit 
SGOS# (config services) rtsp 
SGOS# (config services rtsp) view 
Port: 554 IP: 0.0. 0.0 

Properties: transparent, explicit, 



Type : rams 

enabled 



Type : rtsp 

enabled 



Managing SOCKS Services 

By default, a SOCKS service is configured with explicit attribute on port 1080, but not enabled. You 
can create additional SOCKS services. 

To enable a SOCKS port service, complete the steps below. To configure SOCKS gateway forwarding, 
see "SOCKS Gateway Configuration" on page 867. 



Note: The version of SOCKS used is controlled through policy. For example, to use only 

SOCKSv5: 

<proxy> client . protocol=socks 
ALLOW socks . version=4 deny 
DENY 



To Create or Edit a SOCKS Port Service through the Management Console 

1. Select Configuration>Services>Service Ports. 

2. Click New to create a new SOCKS service or select Edit to enable the existing service; the Add (or 
Edit) Service dialog appears. 

3. Select SOCKS from the Protocol drop-down list. 
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Figure 5-1 1 : SOCKS Edit Service Dialog 

4. The default IP address value is All. To limit the service to a specific IP address, select the IP address 
from the drop-down list. 

5. In the Port field, specify a port number; select Enable. 

6. Click OK; click Apply. 

To Create a SOCKS Port Service through the CLI 

1. At the (config) command prompt, enter the following commands: 

SGOS# (config) services 
SGOS# (config services) socks 

SGOS# (config services socks) create [ip_address:'i port 
SGOS# (config services socks) enable lip_address : ] port 

2. (Optional) View the results: 

SGOS# (config services socks) view 

Port: 1080 IP: 10.25.36.48 Type: socks 

Properties: explicit, enabled 

Managing TCP Tunneling Services 

Tunneling, or port forwarding, is a way to forward TCP traffic. Amy application protocol running over 
TCP can be tunneled using this service. Client-server applications carry out any authentication 
procedures just as they do when TCP tunneling is not involved. 

SGOS uses a tcp : // scheme for TCP-tunnel transactions instead of HTTPS because SGOS does not 
actually know that it is HTTPS that is being tunneled. 

You can use the SOCKS proxy in conjunction with TCP tunnels to compress and accelerate the 
tunnelled traffic. For information on using the SOCKS proxy, see "Configuring a SOCKS Proxy" on 
page 223. 
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Both explicit and transparent TCP tunneling are supported. Which one you use depends on your 
needs. 

Explicit TCP tunneling allows connections to one of the ProxySG's IP addresses. 

Transparent TCP tunneling allows connections to any IP address other than those belonging to the 
ProxySG. TCP tunneling in transparent mode supports categorization as well as blocking of 
destination IP address, port, host, and domain. 



Note: The TCP-Tunnel service does not support content filtering with Websense offbox or ICAP. 



You can use the Management Console or the CLI to create a transparent TCP tunneling protocol. 
When a TCP-Tunnel service is created, it is by default an explicit service and automatically enabled. 

To Create a Transparent or Explicit TCP-Tunnel Port Service through the Management Console 

1. Select Configuration>Services>Service Ports. 

2. Click New; the Add Service dialog appears. 

3. Select TCP-Tunnel from the Protocol drop-down list. 

The Add Service dialog displays. 



Add service (j 




( OK ) [ Cancel j 

Figure 5-12: TCP-Tunnel Add Service Dialog 

4. The default IP address value is All. To limit the service to a specific IP address, select the IP address 
from the drop-down list. 

5. In the Port field, specify a port number; select Enabled. 

6. If you are configuring a transparent TCP-Tunnel service, make sure Transparent is selected in the 
Attributes field; if you are configuring an explicit TCP-Tunnel service, verify Explicit is selected. 

7. Click OK; click Apply. 
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To Create a TCP-Tunnel Transparent or Explicit Port Service through the CLI 

1. At the (config) prompt, enter the following commands to create a transparent or explicit service: 

SGOS# (config) services 

SGOS# (config services) tcp-tunnel 

SGOS# (config services tcp-tunnel) create [ip_address:] port 

where ip_address is the IP address of the ProxySG (use 0 . 0 . 0 . 0 to indicate all available IP 
addresses), and port is the number of the port the ProxySG listens to. You must choose a port 
that is not configured for any other service. 

2. Enable the service to be transparent or explicit. By default, the port service is explicit. 

SGOS# (config services tcp-tunnel) attribute {explicit | transparent} {enable 
| disable} [ip_address:] port 

3. (Optional) View the results. 

SGOS# (config services tcp-tunnel) view 

Port: 7080 IP: 0.0. 0.0 Type: tcp-tunnel 

Properties: transparent, explicit, enabled 

If you created a transparent TCP-Tunnel service, the procedure is complete. If you created an explicit 
TCP-Tunnel service, you must configure a forwarding destination port. 

To Configure a Forwarding Destination Port through the CLI 

1. Create a forwarding destination port, where the ProxySG directs traffic. 

SGOS# (config services tcp-tunnel) exit 
SGOS# (config services) exit 
SGOS# (config) forwarding 

SGOS# (config forwarding) create host_alias ip_address tcp=port 

2. (Optional) View the results: 

SGOS# (config forwarding) view 
Forwarding Groups: (* = host unresolved) 

No forwarding groups defined. 

Individual Hosts: (* = host unresolved) 

Host_Alias 10.25.36.47 tcp=port_number 

Managing the Telnet Shell Proxy Service 

On a new system, Telnet proxy service is configured and disabled on port 23. On an upgrade, Telnet 
proxy service is not created. 

To Enable or Create a Telnet Proxy Service through the Management Console 



Important: To use Telnet to manage the ProxySG, create a Telnet-Console rather than a Telnet 
service. The Telnet service allows you to use Telnet for outbound connections, and 
the ProxySG functions as Shell proxy in that situation. For more information on the 
Telnet-Console, see "Managing the Telnet Console" on page 157. 



1. Select Configuration>Services>Service Ports. 
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2. Click New if you are creating a new Telnet service; highlight the Telnet service and click Edit if you 
are enabling an existing Telnet service; 

The Add or Edit Service dialog appears. 



Add service 




[ OK ] [ Cancel j 

Figure 5-13: Creating a Telnet Service 

3. In the Protocol drop-down list, select Telnet. 

4. The default IP address value is all. To limit the service to a specific IP address, select the IP address 
from the drop-down list. 

5. In the Port field, specify a port number; select Enable. Port 23 is the default. 

Important: You can have only one service on a port, so you must choose a port number for 

the Telnet service that is different from the port chosen for the Telnet Console. 

6. In the Attributes field, select Transparent, Explicit, Send-client-IP (spoofing), or all three. Explicit is the 
default. 



Note: The send-client-IP attribute allows the ProxySG to pretend to be a client, allowing the 

origin content server to see the client's IP address. If an alternate path exists for traffic 
returning from the Internet to the client, the Send-client-IP attribute does not work. 



7. Click OK; Click Apply. 
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To Enable or Create a Telnet Proxy Service through the CLI 



Note: The explicit attribute is enabled by default and the transparent and 

send-client-ip attributes are disabled by default. Note also that only one service can 
use a port, so if you have Telnet-Console enabled on Port 23, you must choose a different 
port number for the Telnet shell proxy. 



From the (config) prompt, enter the following commands: 

SGOS# (config) services 
SGOS# (config services) telnet 

SGOS# (config services telnet) create [ip_address :] port 

SGOS# (config services telnet) attribute (explicit | transparent | 

send-client-ip} enable [ip_address :] port 

SGOS# (config services telnet) enable [ip_address :] port 



where: 



create 


[ ip_address : ] port 


Create a Telnet shell proxy service at the (optional) 
address and port number. 


attribute 


explicit | 
transparent | 
send-client-ip enable 
[ ip_address :] port 


Assign the Telnet shell proxy explicit and transparent 
attributes, and create IP spoofing (where the ProxySG 
pretends to be a client so the OCS can see the client's IP 
address). 

Note: The Send-client-IP attribute allows the ProxySG 
to pretend to be a client, allowing the origin content 
server to see the client's IP address.If an alternate path 
exists for traffic returning from the Internet to the 
client, the Send-client-IP attribute does not work. 


enable 


[ ip_address : ] port 


Enable the new Telnet shell proxy. 



To View the Results: 

SGOS# (config services telnet) view 

Port: 23 IP: 0.0. 0.0 Type: telnet 

Properties: transparent, explicit, disabled 
Port: 24 IP: 10.25.36.47 Type: telnet 

Properties: explicit, enabled 
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A proxy filters traffic, monitors Internet and intranet resource usage, blocks specific Internet and 
intranet resources for individuals or groups, and enhances the quality of Internet or intranet user 
experiences. 

A proxy also serves as an intermediary between a Web client and a Web server and can require 
authentication to allow identity-based policy and logging for the client. The rules used to authenticate 
a client are based on the policies created and implemented through your existing security framework, 
such as LDAP, RADIUS, and IWA, and are further discussed in "Using Authentication Services" on 
page 339. 

Explicit/ Transparent proxy specifies the mode the client requests get to the proxy, 
n Explicit — The default, requiring software configuration for both browser and service. 

□ Transparent — Requires a Layer-4 switch or a WCCP-compliant router. You can also transparently 
redirect requests through a ProxySG by setting the workstation's gateway to the ProxySG IP 
address. You can also use the ProxySG software bridge to transparently proxy requests. 

Some software configuration on the ProxySG is also required to allow the appliance to know what 
traffic to intercept. 

You might also configure both proxy types, depending on the services you require. 

This chapter contains the following topics: 

□ "About Explicit and Transparent Proxy" 

□ "Creating an Explicit Proxy Server" 

□ "Configuring the Transparent Proxy Hardware" 

About Explicit and Transparent Proxy 

Whether you select explicit or transparent proxy deployment is determined by factors such as network 
configuration, number of desktops, desired user experience, and desired authentication approach. 



Note: While you must configure proxying to do authentication, verify the proxy is configured 

correctly and is functioning before adding authentication to the mix. Many network or 
other configuration problems can appear similar to authentication errors. 
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Understanding the Explicit Proxy 

In an explicit proxy configuration, the client (browser) is explicitly configured to use a proxy server. 
The browser is given the IP address and port number of the proxy service (the ProxySG). It is also 
possible to configure the browser to download the proxy settings from a Web server. This is called a 
Proxy Auto-Configuration (PAC) file. When a user makes a request, the browser connects to the proxy 
service and sends the request. Because the browser knows it is talking to a proxy, the browser 
provides the proxy server with the destination server. 

The proxy service accepts the explicit connection to it, and fetches the request from the browser. The 
request identifies the desired origin content server (OCS) and the resource on that server. The proxy 
service uses this information to contact the OCS if necessary. 

The disadvantage to explicit proxy is that each desktop must be properly configured to use the proxy, 
which might not be feasible in a large organization. 

Understanding the Transparent Proxy 

When transparent proxy is enabled, the client (browser) does not know the traffic is being processed 
by a machine other than the OCS. The browser believes it is talking to the OCS, so the request is 
formatted for the OCS and the proxy determines for itself the destination server based on information 
in the request, such as the destination IP address in the packet, or the Host : header in the request. 

To enable the ProxySG to intercept traffic sent to it, you must create a service and define it as 
transparent. The service is configured to intercept traffic for a specified port, or for all IP addresses on 
that port. A transparent HTTP proxy, for example, typically intercepts all traffic on port 80 (all IP 
addresses). 

To make sure that the appropriate traffic is directed to the ProxySG, deploy hardware such as a 
Layer-4 switch or a WCCP router, or the ProxySG appliance's software bridge that can redirect 
selected traffic to the appliance. Traffic redirection is managed through polices you create on the 
redirection device. 

For detailed information on explicit proxies, continue with the next section; for detailed information 
on transparent proxies, continue with "Transparent Proxies" on page 259. 
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Section A: Configuring Explicit Proxies 

You can configure several different explicit proxy servers and services: 

□ Native FTP — See "Configuring the FTP Proxy" on page 185. 

□ PITTP Proxy — See "Managing HTTP Proxy” on page 191. 

□ SOCKS — See "Configuring a SOCKS Proxy" on page 223. 

□ SSL Proxy — See "Configuring an SSL Proxy" on page 235 

□ Shell Proxies — See "Customizing Policy Settings for Shell Proxies" on page 230 

For information on creating an explicit proxy server, regardless of type, continue with "Creating an 
Explicit Proxy Server". 

Creating an Explicit Proxy Server 

If your network does not use transparent proxy, clients on the network must configure their browsers 
to use either an explicit proxy server or a Proxy Auto-Configuration (PAC) file. 

Two PAC files ship with the ProxySG: 

□ PAC file. 

□ Accelerated PAC file. 

They can be accessed at: 

□ https: //ProxySG_IP_Address:8082/ accelerated_pac_base.pac 

□ https: / /ProxySG_IP_Address:8082/proxy_pac_file 
They can be edited with any text editor. 

The ProxySG generates client instructions that describe how to configure Microsoft Internet Explorer, 
Netscape Communicator, and other browsers based on instructions selected by the ProxySG 
administrator. You can configure client instructions for each network adapter in the ProxySG with the 
Configuration>Network>Adapters>lnterface>Settings button. 

After selecting client instructions, the ProxySG administrator directs clients to go to the ProxySG 
home page and follow the instructions in the Browser Configuration section. The ProxySG detects the 
browser installed on the client and displays the appropriate instructions. 

Using the ProxySG as an Explicit Proxy 

To use the ProxySG as an explicit proxy and use services such as SOCKS or FTP, you must provide 
custom instructions to clients instructing them how to configure their browsers to use the ProxySG as 
a proxy server. 
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This is a two-step process, requiring that you add the proxy IP address to the browser and also 
instruct the ProxySG which adapter interface uses the proxy IP address. 

Before the proxy can be used, you must: 

□ Configure the proxy server. 

□ Enable the explicit proxy (whether a service or a server). 

The browsers described here are Internet Explorer 6.0 and Netscape 6.2. If you have different browsers 
or different versions of Internet Explorer or Netscape, refer to the vendor documentation for 
information on configuring proxies. 

From Internet Explorer 

1. Select Tools>lnternet Options>Connections>LAN Settings. 

2. Select Use a proxy server. 

3. Enter the IP address and port number for the proxy, or click Advanced to set proxy server IP 
addresses and port numbers for services such as HTTP, FTP, and SOCKS. (Configure HTTPS 
through the Secure field.) 

4. Click OK to exit the Advanced Settings tab, then continue to click OK until you exit the Tools menu. 
From Netscape 

1. Select Edit>Preferences>Advanced>Proxies. 

2. Select Manual proxy configuration. 

3. Enter proxy server IP addresses and port numbers for services such as HTTP, FTP, SOCKS and 
SSL. 

4. Click OK. 



Note: Explicit proxy allows a redundant configuration using IP address failover among a 

cluster of machines. For information on creating a redundant configuration for failover, 
see "Section L: Configuring Failover" on page 137. 



Configuring Adapter Proxy Settings 

Once the explicit proxy is configured on the browser, decide which adapter interfaces listen for which 
service. Each adapter interface can listen for only one IP address; you can configure multiple proxies 
on one ProxySG using the same IP address. 

To Provide Configuration Instructions through the Management Console 

1. Select Configuration>Network>Adapters. 

2. Select an adapter and the correct interface and click Settings. 

3. Select Using a proxy. 



184 



Chapter 6: Configuring Proxies 



Section A: Configuring Explicit Proxies 

4. Click OK to close the Settings dialog. 

5. Click Apply. 

To Provide Configuration Instructions through the CLI 

At the (config) command prompt, enter the following commands: 

SGOS# (config) interface fast-ethernet interface_# 

SGOS# (config interface interface_#) instructions proxy 

Configuring the FTP Proxy 

In previous SGOS releases, connections to FTP origin content servers were only accomplished over 
HTTP. SGOS 4.x supports Native FTP proxy. 



Note: As in previous releases, FTP requests sent through the HTTP proxy are still valid. 



Configuring an FTP proxy requires ProxySG configuration and specific configuration of the FTP 
client. The service must be enabled on the ProxySG before it can be used. 

Data connections initiated by an FTP client to an FTP server are known as passive mode data 
connections. This type of connection is useful in situations where an FTP server is unable to make a 
connection to an FTP client because the client is located behind a firewall or other similar device 
where outbound connections from the client are allowed, but inbound connections to the client are 
blocked. 

This functionality allows administrators to select how the ProxySG responds to a request from an FTP 
client for a passive mode data connection (PASV command). This functionality does not affect HTTP 
requests for FTP objects (for example, those originating from browsers that are explicitly proxied to a 
ProxySG). 

If the FTP server responds that it supports PASV, but the ProxySG is unable to connect because of a 
firewall blocking the port, the ProxySG only attempts a PORT command. Some FTP clients do not 
open a passive mode data connection to an IP address that is different from the IP address used for the 
control connection. 

Disabling passive mode data connections on the ProxySG servicing requests from this type of FTP 
client might provide a more acceptable response to the end user. 

When passive mode data connections are disabled, the ProxySG returns a response to the FTP client 
indicating that the server does not support passive mode. The FTP client software controls any 
messages displayed to the end user as a result of this response from the ProxySG. 

Limitations 

□ Internet Explorer does not support proxy authentication for Native FTP. 

□ The ProxySG FTP proxy does not support exceptions. 
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Understanding FTP Spoofing 

Using policy, you can spoof the IP addresses for FTP data connections in both transparent and explicit 
deployments, for both active and passive modes; certain deployments are subject to limitations. The 
client and server-side policies are: 

□ ftp .match_client_data_ip (yes) — Matches the source IP address of the ACTIVE data 
connection with the destination IP address of the control connection (client side). 

□ f tp . match_server_data_ip (yes ) — Matches the source IP address of the PASV data connection 
with the source IP address of the ProxySG control connection (server side). 



Note: To always use the ProxySG physical IP address (no spoofing), define policy as 

ftp . match_ [client | server] _data_ip (no) . 



The following points describe the various data flow scenarios: 

□ Outbound client data connection (ProxySG to client) — When the client issues a PORT command, 
the ProxySG opens a data connection to the FTP client with the source IP address of whatever 
destination IP address the client used when opening the control connection. 

□ Inbound client data connection (client to ProxySG) — When the client issues a PASV command, the 
ProxySG returns the IP address and port to which client makes a data connection. 

• Explicit — The ProxySG returns the destination IP address of the control connection; this can 
be a physical or virtual ProxySG IP address. 

• Transparent — The ProxySG returns the IP address of the physical adapter on which the 
control connection arrived. 

□ Outbound server data connection (ProxySG to FTP server) — When the ProxySG issues a PASV 
command upstream, the server returns an IP address and port to connect to. The ProxySG then 
opens a data connection to the server with the same source IP address it used to open the control 
connection. This address is defined by the ref lect_ip property. 

□ Inbound server data connection (FTP server to ProxySG) — When the ProxySG issues a PORT 
command, the ProxySG provides the IP address and port number to which the server makes a 
data connection. 

• The ProxySG sends the control connection's source IP address if that IP is a local ProxySG 
(virtual or physical) IP address; or 

• The ProxySG sends the IP address of the physical adapter that was used to make the outgoing 
control connection. 

FTP Server Limitations 

Consider the following limitations when defining FTP spoofing policy: 
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□ IIS and WS_FTP servers do not support PASV data connections with a source IP address that is 
different from the source IP address of the control connection. 

□ IIS and WS_FTP servers do not support ACTIVE data connections with a destination IP address 
that differs from the source IP address of the control connection. 

Configuring the ProxySG for Native FTP Proxy 

This section describes how to configure the ProxySG through the Management Console and the CLI. 

To Configure Native FTP Proxy through the Management Console 
1. Select Configuration>Services>FTP Proxy. 

FTP Proxy 

- FTP Options 

[^1 Allow caching of FTP objects 

Cache FTP objects for 10 % of the time since last modified date 

Cache FTP objects without last modified date for 24 hours 

0 Allow use of PASV mode to clients 



- Welcome Banner 

Blue Coat FTP Service 



Figure 6-1 : FTP Proxy Tab 

2. Select Allow caching of FTP objects. The default is enabled. 

3. Determine the amount of time in percentage of how long since the object was last modified. The 
default is 10%. 

4. Enter an amount, in hours, that the object remains in the cache before becoming eligible for 
deletion. The default is 24 hours. 

5. Select Allow use of PASV mode to clients. The default is enabled. 

To Configure Native FTP Proxy through the CLI 

1. At the (conf ig) command prompt, enter the following commands: 

SGOS# (config) caching 

SGOS#(config caching) max-cache-size 18 

SGOS# (config caching) ftp 

SGOS# (config caching ftp) enable 

SGOS# (config caching ftp) type-m-percent 20 

SGOS# (config caching ftp) type-n- initial 12 
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where: 



max-cache -size 


megabytes 


The maximum size, in megabytes, of the largest object that 
can stored on the ProxySG. The max- cache - size value 
sets the maximum object size for both HTTP and FTP. 


enable | disable 




Enables or disables the caching of FTP objects. 


type -m-per cent 


percent 


Time to live for objects with a last-modified time. 


type -n- initial 


hours 


Time to live for objects without a last-modified time. 



2. (Optional) View the result. 

SG0S# (config caching ftp) view 
Caching FTP objects is enabled 

FTP objects with last modified date, cached for 20% of last modified time 
FTP objects without last modified date, initially cached for 12 hours 

3. (Optional) Change the default login syntax. The default syntax is Raptor. The ProxySG also 
supports the Checkpoint authentication syntax. The supported Checkpoint formats are: 

• remoteuser@proxyuser@host (in USER command) for explicit FTP. 

• remotepass@proxypass (in PASS command) for explicit FTP. 

• remoteuser@proxyuser (in USER command) for transparent FTP. 

• remotepass@proxypass (in PASS command) for transparent FTP. 

Enter the following command to change the login syntax: 

SGOS# (config) ftp login-syntax {raptor | checkpoint} 



Note: Neither proxy authentication for transparent FTP nor proxy chaining are supported with 

the Checkpoint syntax. 



Enabling the FTP Service 

By default, an FTP service is already created with explicit and transparent attributes, but it is disabled. 
You must enable the FTP port before it can be used. 

To Create and Enable a Native FTP Port Service through the Management Console 

1. Select Configuration>Services>Service Ports. 

2. Click New; the Add Service dialog appears. 
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Figure 6-2: FTP Add Service Dialog 

3. In the Protocol drop-down list, select FTP. 

4. The default IP address value is All. To limit the service to a specific IP, select the IP from the 
drop-down list. 

5. In the Port field, specify a port number; select Enabled. 

6. Select the FTP attributes, as required: Explicit, Transparent, or both. 

7. Click OK; Click Apply. 

To Create a Native FTP Port Service through the CLI 

1. At the (config) command prompt, enter the following commands: 

SGOS# (config) services 
SGOS# (config services) ftp 

SGOS# (config services ftp) create [ip^address:] port 

SGOS# (config services ftp) attribute passive-mode {enable | disable} 

SGOS# (config services ftp) attribute explicit enable [ip_address :] port 
SGOS# (config services ftp) attribute transparent enable [ip_address :] port 

2. (Optional) View the results. 

SGOS# (config services ftp) view 

Port: 25 IP: 0.0. 0.0 Type: ftp 

Properties: transparent, explicit, enabled, passive-allowed 

Configuring FTP Clients 

FTP clients must be configured as follows: 

□ Enable firewall. 
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□ Select USER with no logon. 

□ For proxy authentication, select USER remotelD @ remoteHost firelD and specify a proxy username 
and password. 

Example 

The following graphic demonstrates configuring a WSFtp client. 




Figure 6-3: Configuring the WSFtp Client for Native FTP 

Configuring FTP Connection Welcome Banners 

You can customize banners that usually describe the policies and content of the FTP server displayed 
to FTP clients. Without modification, the ProxySG sends a default banner to newly-connected FTP 
clients: Welcome to Blue Coat ftp. Flo wever, you might not want users to know that a Blue Coat 
ProxySG exists on the network. A default banner can be defined in the Management Console or the 
CLI, but other banners defined for specific groups can be created in policy layers. 



Note: Configurable banners are only displayable when FTP is explicit through the ProxySG. In 

transparent deployments, the banner is sent to the client when proxy authentication is 
required; otherwise, the banner is forwarded from the FTP server. 



To Define the Default FTP Banner through the Management Console 

1. Select Configuration>Services>FTP Proxy. 

2. In the Welcome Banner field, enter a line of text that is displayed on FTP clients upon connection. If 
the message length spans multiple lines, the ProxySG automatically formats the string for 
multiline capability. 

3. Click Apply. 
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Welcome Banner 

You are logged into the FTP service. 



Figure 6-4: Configuring an FTP Connection Welcome Banner 

To Define the Default FTP Banner through the CLI 

At the (config) prompt, enter the following command: 

#SGOS# (conf ig) ftp 

#SGOS# (config) ftp welcome-banner "message" 

To Create Policy that Overrides the Default Banner 

Add the following property to a policy: 

< Proxy > 

f tp . welcome_banner "message" 

If entering text that spans more than one line, use $ (crlf ) for line breaks. 

Managing HTTP Proxy 

By default, an HTTP proxy service, with both explicit and transparent attributes set, is enabled on 
port 80. To change the attributes of the proxy service or create new HTTP proxy services, see 
"Managing HTTP Services" on page 168. 

The HTTP proxy is the first line of defense for the ProxySG, controlling all traffic that arrives on 
port 80 to the ProxySG. To control that traffic and improve performance, you can: 

□ Set default caching policies to configure the length of time an object or negative response is 
cached, whether objects are always revalidated before being served, whether server certificates 
are verified by default, and how headers are parsed. For more information, see "Setting Default 
HTTP Proxy Policy" on page 196. 

□ Configure the HTTP proxy as a server accelerator. For more information, see "Choosing the HTTP 
Proxy Profile" on page 200. 

□ Set a limit to the maximum bandwidth the ProxySG is allowed to use for refreshing objects in the 
background. For more information, see "Configuring Refresh Bandwidth for the HTTP Proxy" on 
page 195. 

□ Compress and decompress content. For more information, see "Understanding HTTP 
Compression" on page 211. 
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Note: Use of the compression feature is a trade-off among three resources: server-side 

bandwidth, client side-bandwidth, and CPU. If server-side bandwidth is expensive 
compared to CPU, always request compressed content from the OCS. If CPU is 
comparatively expensive, then the ProxySG should ask the server for the compression 
formats that the client asked for and forward whatever the server returns. 



The HTTP proxy is designed to control Web traffic, providing: 

□ Security 

□ Authentication 

□ Virus Scanning and Patience Pages 

□ Performance 

• Default HTTP Proxy Policy 

• HTTP Proxy Caching Profiles 

• Byte-Range Support 

• Refresh Bandwidth 

• Compression 

This chapter deals with HTTP proxy performance. See also: 

□ Chapter 8: "Security and Authentication" on page 309 to learn about controlling access to the 
ProxySG, Internet, intranet, and making decisions based on user identity. 

□ "Forms-Based Authentication” on page 473 for information about using Web forms for 
authentication. 

□ See "About Content Scanning" on page 513 for information about virus scanning and sending 
patience pages to explain the delays that can occur when scanning for viruses before serving data. 

Configuring HTTP Proxy Performance 

Understanding Default HTTP Proxy Policy 

Using the ProxySG Management Console or CLI, you can configure global defaults that determine 
HTTP proxy caching policy, such as the maximum size of cacheable objects, the length of time that 
negative responses remain in the cache, whether the ProxySG revalidates each object before serving it, 
whether the server certificate is verified by default, and how headers are parsed. 

For information about setting default policy for HTTP proxy caching, see "Setting Default HTTP 
Proxy Policy" on page 196. 

HTTP Proxy Acceleration Profiles 

You have a choice of three profiles to use for the ProxySG: 
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□ Normal (the default setting) acts as a client accelerator, and is used for enterprise deployments 

□ Portal acts as a server accelerator, and is used for Web hosting 

□ Bandwidth Gain is used for ISP deployments 

For information on HTTP profiles, see "Choosing the HTTP Proxy Profile" on page 200. 

Byte-Range Support 

If a client makes a request using the Range : HTTP header, the ProxySG serves the requested portions 
of the file from the cache if byte-range support is enabled (the default). If byte range support is 
disabled, all such requests are forwarded to the origin content server and the response is not cached. 
For information on using byte-range support to determine how the ProxySG handles byte-range 
requests, see "Configuring HTTP for Bandwidth Gain" on page 208. 

Refresh Bandwidth 

Refresh bandwidth refers to server-side bandwidth used for all forms of asynchronous refresh activity. 
The default configuration is to allow the ProxySG to manage refresh bandwidth. The ProxySG 
manages the bandwidth in order to preserve the maximum freshness of accessed objects. However, 
sometimes the automatic refresh bandwidth amount is too high. It is not unusual for refresh 
bandwidth to spike up occasionally, depending on access patterns at the time. If necessary, you can 
impose a limit on refresh bandwidth. To limit the refresh bandwidth to a specified amount, you must 
disable automatic management of the bandwidth and explicitly set a bandwidth limit. Setting the 
refresh bandwidth amount too low can lower the estimated freshness of objects in the cache. If you set 
the refresh bandwidth amount to zero, the ProxySG does not do active refresh at all. 

For information about configuring refresh bandwidth, see "Configuring Refresh Bandwidth for the 
HTTP Proxy" on page 195. 

Compression 

Compression is disabled by default. If compression is enabled, the HTTP proxy forwards the 
supported compression algorithm (either deflate or gzip) from the client's request 
(Accept -Encoding : request header) to the server as is, and attempts to send compressed content to 
client whenever possible. This allows the ProxySG to send the response as is when the server sends 
compressed data, including non-cacheable responses. Any unsolicited encoded response is forwarded 
as is to the client. 

For more information on compression, see "Understanding HTTP Compression" on page 211. 

Understanding HTTP Terms 

□ Asynchronous Adaptive Refresh (AAR) — This allows the ProxySG to keep cached objects as fresh 
as possible, thus reducing response times. The AAR algorithm allows HTTP proxy to manage 
cached objects based on their rate of change and popularity: an object that changes frequently 
and/ or is requested frequently is more eligible for asynchronous refresh compared to an object 
with a lower rate of change and / or popularity. 
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□ Asynchronous Refresh Activity — Refresh activity that does not wait for a request to occur, but that 
occurs asynchronously from the request. 

□ Bandwidth Gain — A measure of the difference in client-side and server-side Internet traffic 
expressed in relation to server-side Internet traffic. It is managed in two ways: you can enable or 
disable bandwidth gain mode or you can select the Bandwidth Gain profile (this also enables 
bandwidth gain mode). See "Configuring the HTTP Proxy Profile" on page 206 for information 
about configuring bandwidth gain. 

□ Byte-Range Support — The ability of the ProxySG to respond to byte-range requests (requests with 
a Range : HTTP header). 

□ Cache-hit — An object that is in the ProxySG and can be retrieved when an end user requests the 
information. 

□ Cache-miss — An object that can be stored but has never been requested before; it was not in the 
ProxySG to start, so it must be brought in and stored there as a side effect of processing the 
end-user's request. If the object is cacheable, it is stored and served the next time it is requested. 

□ Compression — An algorithm that reduces a file's size but does not lose any data. The ability to 
compress or decompress objects in the cache is based on policies you create. Compression can 
have a huge performance benefit, and it can be customized based on the needs of your 
environment: Whether CPU is more expensive (the default assumption), server-side bandwidth is 
more expensive, or whether client-side bandwidth is more expensive. 

□ Freshness — A percentage that reflects the objects in the ProxySG cache that are expected to be 
fresh; that is, the content of those objects is expected to be identical to that on the OCS (origin 
content server). 

□ Maximum Object Size — The maximum object size stored in the ProxySG. All objects retrieved that 
are greater than the maximum size are delivered to the client but are not stored in the ProxySG. 

□ Negative Responses — An error response received from the OCS when a page or image is 
requested. If the ProxySG is configured to cache such negative responses, it returns that response 
in subsequent requests for that page or image for the specified number of minutes. If it is not 
configured, which is the default, the ProxySG attempts to retrieve the page or image every time it 
is requested. 

□ Refresh Bandwidth — The amount of bandwidth used to keep stored objects fresh. By default, the 
ProxySG is set to manage refresh bandwidth automatically. You can configure refresh bandwidth 
yourself, although Blue Coat does not recommend this. 

□ Variants — Objects that are stored in the cache in various forms: the original form, fetched from the 
OCS; the transformed (compressed or uncompressed) form (if compression is used). If a required 
compression variant is not available, then one might be created upon a cache-hit. (Note: 
policy-based content transformations are not stored in the ProxySG.) 
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Configuring Refresh Bandwidth for the HTTP Proxy 

The ProxySG uses as much bandwidth as necessary for refreshing to achieve the desired access 
freshness. 

The amount of bandwidth used varies depending on client demands. If you determine that the 
ProxySG is using too much bandwidth (by reviewing the logged statistics and examining current 
bandwidth used shown in the Refresh bandwidth field), you can specify a limit to the amount of 
bandwidth the ProxySG uses to try to achieve the desired freshness. Be aware, however, that if you 
limit the amount of bandwidth the ProxySG can use, you might prohibit the ProxySG from achieving 
the desired freshness. If the refresh bandwidth configuration remains at the recommended 
default — Let the ProxySG Appliance manage refresh bandwidth (recommended) in the Management 
Console or SGOS# (config caching) refresh automatic in the CLI — then the ProxySG uses 
whatever bandwidth is available in its efforts to maintain 99.9% estimated freshness of the next access. 

To Set Refresh Bandwidth through the Management Console 

1. Select Configuration>Services>HTTP Proxy>Freshness. 



Freshness j Policies | Acceleration Profile 

- Access freshness 

Estimated access freshness is 100.0 percent. 

This value can vary depending on a number of factors 
including refresh bandwidth limits and load related network traffic. 



- Refresh bandwidth 

(♦) Let the ProxySG Appliance manage refresh bandwidth (recommended) 

0 Limit refresh bandwidth to 200 | kilobits/sec 

Current refresh bandwidth used is 0 kilobits/sec. 

Note that limiting the refresh bandwidth too much may lower 
the estimated access freshness value. 

Figure 6-5: Freshness Tab 

The Refresh bandwidth field displays the refresh bandwidth options. The default setting is to allow 
the ProxySG to manage refresh bandwidth automatically. 



Important: Blue Coat strongly recommends that you not change the setting from the default. 



2. Do one of the following: 

• To turn off automatic bandwidth refresh, select Limit refresh bandwidth to (not recommended). 
Enter a new value into the kilobits/sec field, if necessary. 

• To return the ProxySG to automatic bandwidth refresh, select Let the ProxySG Appliance 
manage refresh bandwidth (recommended). 

3. Click Apply. 
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To Set Refresh Bandwidth through the CLI 

1 . To disable automatic bandwidth refresh (not recommended), enter the following commands at the 
(config) command prompt: 

SGOS# (config) caching 

SGOS# (config caching) refresh no automatic 

2. (Optional) To adjust the kilobit/sec refresh bandwidth value, enter the following commands: 



Note: Adjusting the refresh bandwidth value has no effect if you do not also turn off the 

automatic refresh bandwidth option (you must perform Step 1). You can skip Step 2 if the 
refresh bandwidth value is acceptable (200 Kbps is the default). 



SGOS# (config) caching 

SGOS# (config caching) refresh bandwidth kbps 

3. To return the ProxySG to automatic bandwidth refresh (recommended), enter the following 
commands: 

SGOS# (config) caching 

SGOS# (config caching) refresh automatic 

4. (Optional) View the (truncated) results: 

SGOS# (config caching) view 
Refresh: 

Estimated access freshness is 100.0% 

Let the ProxySG Appliance manage refresh bandwidth 
Current bandwidth used is 0 kilobits/sec 

To view all HTTP settings, see "Viewing HTTP Settings through the CLI" on page 210. 

Setting Default HTTP Proxy Policy 

Using the ProxySG Management Console or CLI, you can configure global defaults that determine 
HTTP proxy policy, such as the maximum size of cacheable objects, the length of time that negative 
responses remain in the cache, whether the ProxySG revalidates each object before serving it, whether 
the server certificate is verified by default, and how headers are parsed. 

Other policy can be controlled only by using Blue Coat Content Policy Language (CPL). This section is 
about using the Management Console or CLI to set default HTTP proxy policy; see "Creating a Proxy 
Layer to Manage Proxy Operations" on page 330 for information about using CPL to configure HTTP 
proxy caching. 



Note: Tolerant HTTP request parsing can only be done through the CLI; it is not available 

through the Management Console. 



To Set HTTP Default Proxy Policy through the Management Console 
1. Select Configuration>Services>HTTP Proxy>Policies. 
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Freshness Policies | Acceleration Profile 




Figure 6-6: Policies Tab 
2. Fill in the fields as appropriate: 

• In the Do not cache objects larger than field, enter the maximum object size to cache. The default 
is 1024 MB. This configuration determines the maximum object size to store in the ProxySG. 
All objects retrieved that are greater than the maximum size are delivered to the client but are 
not stored in the ProxySG. 

• In the Cache negative responses for field, enter the number of minutes the ProxySG stores 
negative responses. The default is 0, meaning that the ProxySG does not cache negative 
responses and always attempts to retrieve the object. 

The OCS might send a client error code (4xx HTTP response) or a server error code (5xx HTTP 
response) as a response to some requests. If the ProxySG is configured to cache such negative 
responses, it returns that response in subsequent requests for that page or image for the 
specified number of minutes. If it is not configured, which is the default, the ProxySG 
attempts to retrieve the page or image every time it is requested. 

If you enter a number of minutes into this field, then the response times improve, but you 
could receive negative responses to requests that might otherwise have been served for that 
period of time. 

• To always verify that each object is fresh upon access, select the Always check with source before 
serving object checkbox. Enabling this setting has a significant impact on performance because 
HTTP proxy revalidates requested cached objects with the OCS before serving them to the 
client, resulting in a negative impact on response times and bandwidth gain. Therefore, do not 
enable this configuration unless absolutely required. 

• If you communicate with an OCS through HTTPS and want the origin content server's 
certificate to be verified by the ProxySG, verify that Verify server certificate for secure connections 
is selected. 
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• The default is to parse HTTP meta tag headers in HTML documents if the MIME type of the 
object is text/HTML. The function of all meta tags is same as the corresponding HTTP 
headers. 

To disable meta-tag parsing, remove the check from the checkbox for: 

• Parse “cache-control” meta tag 

The following sub-headers are parsed when this checkbox is selected: private, 
no-store, no-cache, max-age, s-maxage, must -revalidate, proxy-revalidate. 

• Parse “expires” meta tag 

• Parse “pragma-no-cache” meta tag 
3. Click Apply. 



To Set HTTP Proxy Default Policy through the CLI 



1 . 



At the (config) command prompt, enter the following commands: 



SGOS# (config) 
SGOS# (config 
SGOS# (config 
SGOS# (config 
-or- 

SGOS# (config 



caching 

caching) 

caching) 

caching) 

caching) 



max-cache-size megabytes 
negative-response minutes 
always -verify- source 

no always -verify- source 



where: 



max- cache -size 


megabytes 


The maximum size, in megabytes, of the largest object 
that can stored on the ProxySG. The 
max-cache -size sets the maximum object size for 
both HTTP and FTP. 


negative -response 


minutes 


The amount of time, in minutes, that the ProxySG 
remembers that an object is not stored. 


always -ver if y- 
source 




Ensures that every object is always fresh upon access. 
This has a significant impact on performance because 
HTTP proxy revalidates requested cached objects with 
the OCS before serving them to the client, resulting in 
a negative impact on response times and bandwidth 
gain. Therefore, do not enable this configuration item 
unless absolutely required. 


no 


always -verify 
source 


The default setting. This tells the Proxy SG never to 
check objects on the source before serving them to the 
client. 



Note: If you use HTTPS, you might want to change the verify-server certificate from the default 

of enabled to suppress verification of the OCS certificate (step 2). 
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2. (Optional) To enable or disable the verity-server certificate setting, enter one of the following 
commands: 

SGOS# (config caching) exit 

SGOS# (config) http ssl-verify-server 

-or- 

SGOS# (config) http no ssl-verify-server 



Note: The http ssl-verify-server command is overridden by the CPL property 

server .certificate . validate or the forwarding hosts ssl -verify- server 
command , if explicitly set. 



3. (Optional) To enable or disable meta-tag parsing (parsing is enabled by default), enter one of the 
following commands: 

SGOS# (config services) exit 

SGOS# (config) http parse meta-tag {cache-control | expires | pragma-no-cache} 

-or- 

SGOS# (config) http no parse meta-tag {cache-control | expires | 
pragma -no -cache} 

To view all HTTP settings, see "Viewing HTTP Settings through the CLI" on page 210. 

Tips on Parsing Meta Tags 

n If ICAP response modification is occurring, the response body modified by the ICAP server is not 
parsed. 

□ Relevant HTTP meta tags must appear within the first 256 bytes of HTTP object body. If the meta 
tag does not appear within the first 256 bytes, it is ignored. 

Tips on Using Meta Tags With Policy 

□ The following CPL properties can be used in the <Cache> layer to control meta tag processing for 
HTTP proxy, HTTP refresh, and HTTP pipeline transactions: 

http . response . parse_meta_tag . Pragma . no-cache (yes | no) 
http . response .parse_meta_tag . Cache-Control (yes | no) 
http . response .parse_meta_tag . Expires (yes [ no) 

□ VPM support for this feature is not available. 

Understanding Tolerant HTTP Request Parsing 

By default, the ProxySG blocks malformed HTTP requests, returning a 400 Invalid Request error. The 
tolerant HTTP request parsing flag causes certain types of malformed requests to be processed instead 
of being rejected. 

By default, a header line not beginning with a <Tab> or space character must consist of a header name 
(which contains no <Tab> or space characters), followed by a colon, followed by an optional value, or 
an error is reported. With tolerant request parsing enabled, a request header name is allowed to 
contain <Tab> or space characters, and if the request header line does not contain a colon, then the 
entire line is taken as the header name. 
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A header containing one or more <Tab> or space characters, and nothing else, is considered 
ambiguous. Blue Coat does not know if this is a blank continuation line or if it is the blank line that 
signals the end of the header section. By default, an ambiguous blank line is illegal, and an error is 
reported. With tolerant request parsing enabled, an ambiguous blank line is treated as the blank line 
that signals the end of the header section. 

To Enable the HTTP Tolerant Request Parsing Flag through the CLI 



Note: This feature is only available through the CLI. It cannot be set through the Management 

Console. 



From the (conf ig) prompt, enter the following command to enable tolerant HTTP request parsing 
(the default is disabled): 

SGOS# (config) http tolerant-request-parsing 

To disable HTTP tolerant request parsing, enter the following command: 

SGOS# (config) http no tolerant-request-parsing 

To view all HTTP settings, including http tolerant -request -parsing if it is enabled, see "Viewing 
HTTP Settings through the CLI” on page 210. 

Choosing the HTTP Proxy Profile 

You can select from among three profiles for the HTTP proxy, depending on your needs, and you can 
also create a customized profile from the three available. 

The three profiles are: 

□ Normal, which acts as a client-accelerator and is used for enterprise deployments 

□ Portal, which acts as a server accelerator and is used for Web-hosting 

□ Bandwidth, which is used for ISP deployments 

The table below shows the configuration for each profile. 

Table 6.3: Normal, Portal, and Bandwidth Gain Profiles 



Configuration 


Normal Profile 


Portal Profile 


Bandwidth Gain 


Pipeline embedded objects in client requests 


Enabled 


Disabled 


Disabled 


Pipeline embedded objects in prefetch requests 


Enabled 


Disabled 


Disabled 


Pipeline redirects for client requests 


Enabled 


Disabled 


Disabled 


Pipeline redirects for prefetch requests 


Enabled 


Disabled 


Disabled 


Cache expired objects 


Enabled 


Disabled 


Enabled 


Bandwidth Gain Mode 


Disabled 


Disabled 


Enabled 
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Table 6.3: Normal, Portal, and Bandwidth Gain Profiles (Continued) 



Configuration 


Normal Profile 


Portal Profile 


Bandwidth Gain 


Substitute GET for IMS (if modified since) 


Disabled 


Enabled 


Enabled 


Substitute GET for PNC (Pragma no cache) 


Disabled 


Enabled 


Does not change 


Substitute GET for HTTP 1.1 conditionals 


Disabled 


Enabled 


Enabled 


Substitute GET for IE (Internet Explorer) reload 


Disabled 


Enabled 


Does not change 


Never refresh before expiration 


Disabled 


Enabled 


Enabled 


Never serve after expiration 


Disabled 


Enabled 


Does not change 



When an SG appliance is first manufactured, it is set to a Normal profile. Depending on your needs, 
you can use the Bandwidth Gain profile or the Portal profile. You can also combine needed elements of 
all three profiles. 

Using the Normal Profile 

Normal is the default profile and can be used wherever the SG appliance is used as a normal forward 
proxy. This profile is typically used in enterprise environments, where the freshness of objects is more 
important than controlling the use of server-side bandwidth. The Normal profile is the profile that 
most follows the HTTP standards concerning object revalidation and staleness. Additionally, 
prefetching (pipelining) of embedded objects and redirects is enabled, which reduces response time 
for clients. 

Using the Portal Profile 

When configured as a server accelerator, the SG appliance improves object response time to client 
requests, scalability of the origin content server (OCS) site, and overall Web performance at the OCS. 
A server accelerator services requests meant for an OCS as if it is the OCS itself. 

Because an OCS can actually consist of many servers — a single Web server or an entire server 
farm — OCSs are identified by domain name or IP address. To the SG appliance, the domain name or 
IP address is treated as the OCS, regardless of how many back-end Web servers might be installed. 

Using the Bandwidth Gain Profile 

The Bandwidth-Gain profile is useful wherever server-side bandwidth is an important resource. This 
profile is typically used in Internet Service Provider (ISP) deployments. In such deployments, the 
freshness of the object is not as important as controlling the use of server-side bandwidth. The 
Bandwidth-Gain profile enables various HTTP configurations that can increase page response times 
and the likelihood that stale objects are served, but that reduces the amount of server-side bandwidth 
required. 
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Understanding HTTP Object Types 

HTTP proxy categorizes HTTP objects into three types: 

□ Type-T: The OCS specifies explicit expiration time. 

□ Type-M: Expiration time is not specified; however, the last modified time is specified by the OCS. 

□ Type-N: Neither expiration nor last modified time has been specified. 

The ProxySG's asynchronous adaptive refresh (AAR) algorithm is normally applied to all three types 
of HTTP objects. To maximize the freshness of the next access to objects in the ProxySG's cache, 
asynchronous revalidations are performed on those objects in accordance with their relative 
popularity and the amount of time remaining before their estimated time of expiration. Estimated 
expiration times vary as object content changes are observed during such asynchronous revalidations. 
This happens even for type-T objects because the expiration times of type-T objects are not always 
perfectly managed by Webmasters of content servers. However, for situations where such 
management can be trusted, certain configuration items exist to reduce speculative revalidation of 
type-T objects. In the following section, the terms revalidation and refresh mean the same thing — to 
assess the freshness of an object by sending a conditional GET request to the object's OCS. 

Understanding HTTP Proxy Profile Configuration Components 



Table 6.1 gives a definition of the customizable HTTP proxy profile settings. Both the Management 
Console field and CLI (conf ig) command text is included. 

Table 6.1 : Description of Profile Configuration Components in the Management Console and CLI 



Management Console 
Checkbox Field 


CLI (config) 

Command 


Definition 


Pipeline embedded 
objects in client request 


http [no] pipeline 
client requests 


This configuration item applies only to HTML 
responses. When this setting is enabled, and the object 
associated with an embedded object reference in the 
HTML is not already cached, HTTP proxy acquires 
the object's content before the client requests the 
object. This improves response time dramatically. If 
this setting is disabled, HTTP proxy does not acquire 
embedded objects until the client requests them. 


Pipeline redirects for 
client request 


http [no] pipeline 
client redirects 


When this setting is enabled, and the response of a 
client request is one of the redirection responses (such 
as 301, 302, or 307 HTTP response code), then HTTP 
proxy pipelines the object specified by the Location 
header of that response, provided that the redirection 
location is an HTML object. This feature improves 
response time for redirected URLs. If this setting is 
disabled, HTTP proxy does not pipeline redirect 
responses resulting from client requests. 
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Table 6.1 : Description of Profile Configuration Components in the Management Console and CLI 



Management Console 
Checkbox Field 


CLI (config) 

Command 


Definition 


Pipeline embedded 
objects in prefetch 
request 


http [no] pipeline 
prefetch requests 


This configuration item applies only to HTML 
responses resulting from pipelined objects. When this 
setting is enabled, and a pipelined object's content is 
also an HTML object, and that HTML object has 
embedded objects, then HTTP proxy also pipelines 
those embedded objects. This nested pipelining 
behavior can occur three levels deep at most. If this 
setting is disabled, HTTP proxy does not engage in 
nested pipelining behavior. 


Pipeline redirects for 
prefetch request 


http [no] pipeline 

prefetch 

redirects 


When this setting is enabled, HTTP proxy pipelines 
the object specified by a redirect location returned by 
a pipelined response. If this setting is disabled, HTTP 
proxy does not try to pipeline redirect locations 
resulting from a pipelined response. 


Substitute Get for IMS 


http [no] 

substitute 

if -modified- since 


If the time specified by the If -Modif ied-Since : 
header in the client's conditional request is greater 
than the last modified time of the object in the cache, 
it is a strong indication that the copy in the cache is 
stale. If so, HTTP proxy does a conditional GET to the 
OCS, based on the last modified time of the cached 
object. 






To control this aspect of the ProxySG's treatment of 
the If -Modif ied-Since : header, disable the 
Substitute Get for IMS setting. When this setting is 
disabled, a client time condition greater than the last 
modified time of the object in the cache does not 
trigger revalidation of the object. 

However, not all objects necessarily have a 
last-modified time specified by the OCS. 
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Table 6.1 : Description of Profile Configuration Components in the Management Console and CLI 



Management Console 
Checkbox Field 


CLI (config) 

Command 


Definition 


Substitute Get for HTTP 
1.1 conditionals 


http [no] 

substitute 

conditional 


HTTP 1.1 provides additional controls to the client 
over the behavior of caches concerning the staleness 
of the object. Depending on various 

Cache-Control : headers, the ProxySG can be 
forced to consult the OCS before serving the object 
from the cache. For more information about the 
behavior of various Cache-Control : header 
values, refer to RFC 2616. 

If the Substitute Get for HTTP 1.1 Conditionals setting 
is enabled, HTTP proxy ignores the following 
Cache-Control : conditions from the client request: 

• "max-stale" [ "=" delta- seconds ] 

• "max-age" "=" delta-seconds 

• "min-fresh" "=" delta-seconds 

• "must-revalidate" 

• "proxy- revalidate" 


Substitute Get for PNC 


http [no] 
substitute 
pragma -no -cache 


Typically, if a client sends an HTTP GET request with 
a Pragma : no -cache or Cache -Control : 
no -cache header (for convenience, both are hereby 
referred to as PNC), a cache must consult the OCS 
before serving the content. This means that HTTP 
proxy always re-fetches the entire object from the 
OCS, even if the cached copy of the object is fresh. 
Because of this, PNC requests can degrade proxy 
performance and increase server-side bandwidth 
utilization. However, if the Substitute Get for PNC 
setting is enabled, then the PNC header from the 
client request is ignored (HTTP proxy treats the 
request as if the PNC header is not present at all). 


Substitute Get for IE 
reload 


http [no] 

substitute 

ie-reload 


Some versions of Internet Explorer issue the 
Accept : * / * header instead of the Pragma : 
no-cache header when you click Refresh. When an 
Accept header has only the * /* value, HTTP proxy 
treats it as a PNC header if it is a type-N object. You 
can control this behavior of HTTP proxy with the 
Substitute GET for IE Reload setting. When this 
setting is enabled, the HTTP proxy ignores the PNC 
interpretation of the Accept : * / * header. 
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Table 6.1 : Description of Profile Configuration Components in the Management Console and CLI 



Management Console 
Checkbox Field 


CLI (config) 

Command 


Definition 


Never refresh before 
expiration 


http [no] 

strict -expiration 

refresh 


Applies only to cached type-T objects. When this 
setting is enabled, the ProxySG does not 
asynchronously revalidate such objects before their 
specified expiration time. When this setting is 
disabled, such objects, if they have sufficient relative 
popularity, can be asynchronously revalidated and 
can, after a sufficient number of observations of 
changes, have their estimates of expiration time 
adjusted accordingly. 


Never serve after 
expiration 


http [no] 

strict -expiration 

serve 


Applies only to cached type-T objects. If this setting is 
enabled, an object is synchronously revalidated 
before being served to a client, if the client accesses 
the object after its expiration time. If this setting is 
disabled, the object is served to the client and, 
depending on its relative popularity, may be 
asynchronously revalidated before it is accessed 
again. 


Cache expired objects 


http [no] cache 
expired 


Applies only to type-T objects. When this setting is 
enabled, type-T objects that are already expired at the 
time of acquisition is cached (if all other conditions 
make the object cacheable). When this setting is 
disabled, already expired type-T objects become 
non-cacheable at the time of acquisition. 
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Table 6.1 : Description of Profile Configuration Components in the Management Console and CLI 



Management Console 
Checkbox Field 


CLI (config) 

Command 


Definition 


Enable Bandwidth Gain 
Mode 


bandwidth- gain 
{disable | enable} 


This setting controls both HTTP-object acquisition 
after client-side abandonment and AAR 
(asynchronous adaptive refresh) revalidation 
frequency. 

• HTTP-Object Acquisition 

When Bandwidth Gain mode is enabled, if a client 
requesting a given object abandons its request, 
then HTTP proxy immediately abandons the 
acquisition of the object from the OCS, if such an 
acquisition is still in progress. When bandwidth 
gain mode is disabled, the HTTP proxy continues 
to acquire the object from the OCS for possible 
future requests for that object. 

• AAR Revalidation Frequency 

Under enabled bandwidth gain mode, objects that 
are asynchronously refreshable are revalidated at 
most twice during their estimated time of 
freshness. With bandwidth gain mode disabled, 
they are revalidated at most three times. Not all 
asynchronously refreshable objects are guaranteed 
to be revalidated. 



Configuring the HTTP Proxy Profile 

You can configure the profile you want from either the Management Console or the CLI. 

To Configure the HTTP Proxy Profile through the Management Console 

1. Select Configuration>Services>HTTP Proxy>Acceleration Profile. 

The Acceleration Profile tab displays (Normal is the default profile). Text appears at the bottom of 
this tab indicating which profile is selected. If you have a customized profile, this text does not 
appear. 



206 



Chapter 6: Configuring Proxies 



Section A: Configuring Explicit Proxies 



Freshness | Policies Acceleration Profile 




Figure 6-7: Acceleration Profile Tab 



Important: If you have a customized profile and you click one of the Use Profile buttons, no 

record of your customized settings remains. However, once the ProxySG is set 
to a specific profile, the profile is maintained in the event the ProxySG is 
upgraded. 



2. To select a profile, click one of the three profile buttons (Use Normal Profile, Use Bandwidth Gain 
Profile, or Use Portal Profile). 

The text at the bottom of the Acceleration Profile tab changes to reflect the new profile. 

Note: You can customize the settings, no matter which profile button you select. 

3. (Optional) To customize the profile settings, select or deselect any of the check boxes (see Table 6.1 
on page 202 for information about each setting). 

4. Click Apply. 

To Configure the HTTP Proxy Profile through the CLI 

1. At the (config) command prompt, enter the profile you want: 

SGOS# (config) profile {normal | portal | bwgain} 

2. (Optional) Use the following commands to customize the profile settings (see Table 6.1 on 
page 202 for information about these settings): 

SGOS# (config) http [no] pipeline client requests 

SGOS# (config) http [no] pipeline client redirects 

SGOS# (config) http [no] pipeline prefetch requests 

SGOS# (config) http [no] pipeline prefetch redirects 

SGOS# (config) http [no] substitute if -modified- since 
SGOS# (config) http [no] substitute conditional 
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SGOS# (config) http [no] substitute pragma-no-cache 
SG0S# (conf ig) http [no] substitute ie-reload 
SGOS# (config) http [no] strict-expiration refresh 
SGOS# (conf ig) http [no] strict-expiration serve 
SGOS# (conf ig) http [no] cache expired 
SGOS# (conf ig) bandwidth-gain {disable | enable} 



3. (Optional) View the settings. (This example assumes you have selected the Portal profile.) 

SGOS# (config) show profile 
SG is currently using the Normal Profile 
Pipeline client requests: Enabled 

Pipeline client redirects: Enabled 

Pipeline prefetch requests: Enabled 

Pipeline prefetch redirects: Enabled 

Substitute Get "if -modified- since " : Disabled 

Substitute Get "pragma: no-cache": Disabled 

Substitute HTTP 1.1 Conditional Get: Disabled 
Substitute Internet Explorer reload: Disabled 
Never refresh before expiration: Disabled 

Never serve after expiration: Disabled 

Cache expired objects: Enabled 

Bandwidth gain mode: Disabled 



You can view all HTTP settings. See "Viewing HTTP Settings through the CLI" on page 210 for more 
information. 

Configuring HTTP for Bandwidth Gain 

In addition to the configuration items related to top-level profiles, other configurable items also affect 
bandwidth gain. You can set the top-level profile and adjust various related configuration items to fine 
tune ProxySG for your needs (see "Configuring the HTTP Proxy Profile" on page 206), and you can 
provide additional fine-tuning with the following configuration items: 

□ Byte-range support 

□ Revalidate pragma-no-cache 

Byte-range requests can be made with a PNC header. To serve these requests from the cache, enable 
the revalidate PNC setting (see "Understanding Revalidate Pragma-No-Cache" below). 

Understanding Byte-Range Support 

If a client requests a byte range using the Range : HTTP header, the ProxySG serves the requested 
portions of the file from the cache if byte-range support is enabled (the default). If byte range support 
is disabled, all such requests are forwarded in a non-cacheable way to the origin content server. 

Byte-range configuration can significantly affect bandwidth gain where heavy use of range requests is 
expected. Download managers (such as NetAnts®) typically use byte-range requests heavily. 
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With byte-range support enabled, if the object is already cached and does not need to be reloaded 
from the OCS, the ProxySG serves the byte-range request from the cache only. But if the object is not in 
the cache, or if a reload of the object is required, the ProxySG might treat the byte-range request as if 
byte-range support is disabled and serve the object from the cache. It is important to note that HTTP 
proxy never caches partial objects, even if byte-range support is enabled. 

If byte-range support is disabled, HTTP treats all byte-range requests as non-cacheable. Such requests 
are never served from the cache, even if the object exists in the cache. The client's request is sent 
unaltered to the OCS and the response is not cached. Thus a byte-range request has no effect on the 
cache if byte-range support is disabled. 

HTTP proxy categorizes the range requests in following three categories when byte-range support is 
enabled: 

□ Type-1: 0-N: Range request for first N bytes of the object 

□ Type-2: N-M: Range request from N bytes to M bytes of the object 

□ Type-3: -N: Range request for last N bytes of the object 

If the object does not exist in the cache, and a byte-range request is received with the first range being 
type-1 or type-2, and the start byte of the first requested range is within 14336 bytes (hard coded 
threshold), then the entire object is retrieved from the OCS and cached in the ProxySG. Even though 
HTTP proxy retrieves the entire object from the OCS, it sends an appropriate byte-range response to 
the client. If the object does not exist in the cache, and if the first range in the request is not of type-1 or 
type-2, or if the start byte of the first requested range is beyond 14336 bytes, then the client's request is 
sent unaltered to the OCS and the response is not cached. 

If the object exists in the cache, and if a range request with an effective PNC (the PNC header is not 
substituted or revalidated — see "Understanding Revalidate Pragma-No-Cache" below) is made, and 
the first range in the request is either type-3 or type-1 or 2 with a start byte offset greater than 14336 
bytes, then, even if the object exists in the cache, the transaction is made non-cacheable (the request is 
sent to the OCS without any modification and the response is not cached). If an object exists in the 
cache and a byte-range request is made without the PNC header, then the byte-range response is 
satisfied from the cache. 

Most download managers make byte-range requests with a PNC header. To serve such requests from 
the cache, the revalidate pragma-no-cache option should be configured along with byte-range support 
(see "Understanding Revalidate Pragma-No-Cache" below). 

To Configure Byte- Range Support through the CLI 



Note: Enabling or disabling byte-range support can only be configured through the CLI. 



To enable or disable byte-range support, enter one of the following commands at the (conf ig) 
command prompt: 

SGOS# (config) http byte-ranges 

-or- 

SGOS# (config) http no byte-ranges 

To view all HTTP settings, see "Viewing HTTP Settings through the CLI" on page 210. 



209 



Blue Coat ProxySG Configuration and Management Guide 



Section A: Configuring Explicit Proxies 



Understanding Revalidate Pragma-No-Cache 



The pragma-no-cache (PNC) header in a client's request can affect the efficiency of the proxy from a 
bandwidth gain perspective (this behavior is described in Table 6.1 in the Substitute Get for PNC 
configuration description). If you do not want to completely ignore PNC in client requests (which you 
can do by using the Substitute Get for PNC configuration), you can lower the impact of the PNC by 
enabling the revalidate-pragma-no-cache setting. When the revalidate-pragma-no-cache 
setting is enabled, a client's non-conditional PNC-GET request results in a conditional GET request 
sent to the OCS if the object is already in the cache. This gives the OCS a chance to return the 304 Not 
Modified response, thus consuming less server-side bandwidth, because it has not been forced to return 
full content even though the contents have not actually changed. By default, the revalidate PNC 
configuration is disabled and is not affected by changes in the top-level profile. When the Substitute 
Get for PNC configuration is enabled (see "Configuring the HTTP Proxy Profile" for configuration 
information), the revalidate PNC configuration has no effect. 

To Configure the Revalidate PNC Setting through the CLI 



Note: The revalidate pragma-no-cache setting can only be configured through the CLI. 



To enable or disable the revalidate PNC setting, enter one of the following commands at the (conf ig) 
command prompt: 

SGOS# (config) http revalidate-pragma-no-cache 

-or- 

SGOS# (config) http no revalidate-pragma-no-cache 

To view all HTTP settings, see "Viewing HTTP Settings through the CLI" below. 



You can view the existing HTTP settings by entering the following command: 

SGOS# (config) show http 

Supported protocol version: HTTP 1.1 

Caching options: 

Cache authenticated data: enabled 



Viewing HTTP Settings through the CLI 



Cache expired objects: 
Cache personal pages : 
Strip From Headers : 
Byte range support : 



enabled 

disabled 

disabled 

enabled 



Force NTLM on proxy IE: disabled 

Rewrite redirects for XP : disabled 



Revalidate "pragma: no-cache": disabled 

WWW redirect if host not found: enabled 

Force explicit expirations: 

Never refresh before: disabled 



Never serve after: 
Add headers : 



disabled 



"X- forwarded- for " : 



" Front -end-https " : 
"Via" : 



disabled 

disabled 

disabled 
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"Client-ip" : disabled 

Parsing options: 

HTML meta tag "Cache-Control": 

HTML meta tag "Expires": 

HTML meta tag "Pragma: no-cache": 
Persistent connections: 

Client connections: enabled 

Server connections: enabled 

Pipeline : 

Client requests: enabled 

Client redirects: enabled 

Prefetch requests: enabled 

Prefetch redirects : enabled 

Substitute simple Get for: 

Get " if -modif ied-since" : disabled 

Get "pragma: no-cache": disabled 

HTTP 1.1 Conditional get: disabled 
Internet Explorer reload: disabled 
Proprietary header extensions: 

Blue Coat extensions: disabled 

FTP proxy: 

Url path is: absolute 

Conf iguration/access log uploads: 
Persistent connection timeouts: 



Server : 


900 


Client : 


360 


Receive timeouts: 


Server : 


180 


Client : 


120 


Refresh : 


90 


Https : 


ssl-verify-server : 


enabled 


tolerant -request -par sing: 


enabled 



enabled 

enabled 

enabled 



from root 
will use PASV 



Understanding HTTP Compression 

Compression reduces a file size but does not lose any data. Whether you should use compression 
depends upon three resources: server-side bandwidth, client-side bandwidth, and ProxySG CPU. If 
server-side bandwidth is more expensive in your environment than CPU, always request compressed 
content from the origin content server (OCS). However, if CPU is comparatively expensive, the 
ProxySG should instead be configured to ask the OCS for the same compressions that the client asked 
for and to forward whatever the server returns. 

The default configuration assumes that CPU is costlier than bandwidth. If this is not the case, you can 
change the ProxySG behavior. 
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Note: Decompression, content transformation, and recompression increases response time by a 

small amount because of the CPU overhead. (The overhead is negligible in most cases.) 
RAM usage also increases if compression is enabled. 

Compression might also appear to adversely affect bandwidth gain. Because compression 
results in a smaller file being served to the client than was retrieved by the ProxySG from 
the origin content server, bandwidth gain statistics reflect such requests / responses as 
negative bandwidth gain. 



Compression is disabled by default. If compression is enabled, the HTTP proxy forwards the 
supported compression algorithm (gzip and deflate) from the client's request (Accept -Encoding : 
request header) to the server as is, and attempts to send compressed content to client whenever 
possible. This allows the ProxySG to send the response as is when the server sends compressed data, 
including non-cacheable responses. Any unsolicited encoded response is forwarded to the client as is. 



Note: If compression is not enabled, the ProxySG does not compress the content if the server 

sends uncompressed content. However, the ProxySG continues to uncompress content if 
necessary to apply transformations. 

Any unsolicited encoded response is forwarded to the client as is. 



Compression is controlled by policy only. 

You can view compression statistics by going to Statistics>System Usage>Client Comp. Gain and Server 
Comp. Gain and Statistics>HTTP/FTP History>Client Comp. Gain and Server Comp. Gain. For information on 
these statistics, see "System Usage Statistics" on page 979 and "HTTP/FTP History Statistics" on 
page 982. 

Understand Compression Behavior 

The ProxySG compression behavior is detailed in the tables below. 



Note: A variant is the available form of the object in the cache — compressed or uncompressed. 

The Content -Encoding : header Identity refers to the uncompressed form of the content. 



Compression increases the overall percentage of cacheable content, increasing the hit rate in terms of 
number of objects served from the cache. 
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For cache-hit compression behavior, see Table 6.2 below. For cache-miss compression behavior, see 
Table 6.3 on page 213. 

Table 6.2: Cache-Hit Compression Behavior 



Accept-Encoding: 
in client request 


Variant Available when 
the Request Arrived 


Variant Stored as a 
Result of the Request 


Content-Encoding: in 
ProxySG response 


Identity 


Uncompressed object 


None 


Identity 


Identity 


No uncompressed object 
gzip compressed 


Uncompressed 


Identity 


gzip, deflate 


Uncompressed object 


gzip compressed 


gzip 


gzip, deflate 


Uncompressed object 
gzip compressed 


None 


gzip 


gzip, deflate 


Uncompressed object 
deflate compressed 


None 


deflate 


deflate 


No uncompressed object 
gzip compressed 


deflate compressed 


deflate 

(This is effectively a cache-miss. 
The ProxySG does not convert 
from gzip to deflate.) 



Table 6.3: Cache-Miss Compression Behavior 



Accept-Encoding: 
in client request 


Accept-Encoding: 
in ProxySG 
request 


Content-Encoding: 
in server response 


Generated variants 


Content-Encoding: 
in ProxySG 
response 


Identity 


Identity 


Identity 


uncompressed object 


Identity 


gzip, deflate 


gzip, deflate 


Identity 


uncompressed object 
gzip-compressed 


gzip 


gzip, deflate 


gzip, deflate 


gzip 


No uncompressed 
object 

gzip-compressed 


gzip 


gzip, deflate, 
compress 


gzip, deflate 


gzip 


No uncompressed 
object 

gzip-compressed 


gzip 


gzip, deflate 


gzip, deflate 


compress (illegal 
response) 


compress 


compress 
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Compression Exceptions 

□ The ProxySG issues a transformation_error exception (HTTP response code 403), when the 
server sends an unknown encoding and the ProxySG is configured to do content transformation. 

□ The ProxySG issues an unsupported_encoding exception (HTTP response code 415 - 
Unsupported Media Type) when the ProxySG is unable to deliver content due to configured 
policy. 

The messages in the exception pages can be customized. For information on using exception pages, 
see "Section D: Defining Exceptions" on page 712. 

Configuring Compression 

Compression behavior can only be configured through policy — VPM or CPL. 

Using VPM to Configure Compression Behavior 

Three objects can be used to configure compression and compression levels through VPM: 

□ Client HTTP compression object: Allows you to determine the behavior when the client wants the 
content in a different form than is in the cache. 

□ Server HTTP compression object: Allows you to enable or disable compression and to set options. 

□ HTTP compression level object: Allows you to set a compression level of low, medium, or high. 
Complete the following steps to manage server and client HTTP compression and compression levels. 

To Add or Edit Client Compression 

1. Create a Web Access Layer: 

• Select Configuration>Policy>Visual Policy Manager; click Launch. 

• Select Policy>Add Web Access Layer from the menu of the Blue Coat VPM window that appears. 

• Type a layer name into the dialog that appears and click OK. 

2. Add an Action object: 

• Right click on the item in the Action column; select Set. 

• Click New in the Set Action Object dialog that appears; select Set Client HTTP Compression. 

The Add Client HTTP Compression Object dialog displays. 
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O Add Client HTTP Compression Object 



Name: |ciientHTTPCompression1 

If client requests compressed and only 
uncompressed content is available: 

<• Compress content before serving it 
C Serve uncompressed content 

If client requests uncompressed content and 
only compressed content is available: 

(• Decompress content before serving it 

C Retrieve uncompressed content from server 





OK 




Cancel 




Help 









Figure 6-8: Add Client HTTP Compression Object Dialog 

• Select the compression options you want to use; click OK. 

• Click OK again; close the VPM window and click Yes in the dialog to save your changes. 

To Add or Edit Server Compression 

1 . Create a Web Access Layer: 

• Select Configuration>Policy>Visual Policy Manager; click Launch. 

• Select Policy>Add Web Access Layer from the menu of the Blue Coat VPM window that appears. 

• Type a layer name into the dialog that appears and click OK. 

2. Add an Action object: 

• Right click on the item in the Action column; select Set. 

• Click New in the Set Action Object dialog that appears; select Set Server HTTP Compression. 

The Add Server HTTP Compression Object dialog displays. 
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Figure 6-9: Add Server HTTP Compression Object Dialog 

• Select compression options; click OK. 

• Click OK again; close the VPM window and click Yes in the dialog to save your changes. 

Using VPM to Set HTTP Compression Levels 

You can control the compression level based on any transaction condition (such as the client IP 
address, the hostname, request/ response headers, and the like). 

To Set Compression Levels 

1 . Create a Web Access Layer: 

• Select Configuration>Policy>Visual Policy Manager; click Launch. 

• Select Policy>Add Web Access Layer from the menu of the Blue Coat VPM window that appears. 

• Type a layer name into the dialog that appears and click OK. 

2. Add an Action object: 

• Right click on the item in the Action column; select Set. 

• Click New in the Set Action Object dialog that appears; select Set HTTP Compression Level. 

The Add HTTP Compression Level Object dialog displays. 




Figure 6-10: Set HTTP Compression Level 
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• Select the compression level needed; click OK. 

• Click OK again; close the VPM window and click Yes in the dialog to save your changes. 

Using Policy to Configure Compression Behavior 

Compression and decompression are allowed if compression is enabled. If compression is not 
enabled, neither compression nor decompression are allowed. 

Policy controls the compression or decompression of content on the ProxySG. If compression is turned 
off, uncompressed content is served to the client if a compressed variant is not available. If 
decompression is turned off, an uncompressed version is fetched from the OCS if the variant does not 
exist and the client requested uncompressed content. 



Note: The ProxySG decompresses the content if transformation is to be applied, even if the 

compression is not enabled. 



You can use server-side or client-side controls to manage compression through policy, as described in 
the following table. 

Table 6.4: Compression Properties 



Compression Properties 


Meaning 


http . allow_compression (yes | no) 


Allow the ProxySG to compress content on 
demand if needed. 


http . allow_decompression (yes | no) 


Allow the ProxySG to decompress content on 
demand if needed. 


http . compression level (low | medium | high) 


Set the compression level to be low (1), medium 
(6), or high (9). Low is the default. 


http . server .accept encoding (client ) 


Turn on only client encodings 


http . server . accept encoding ( identity) 


Turn off all encodings 


http . server . accept encoding (all) 


Turn on all supported encodings, including the 
client's encodings. 


http . server . accept encoding (gzip, deflate) 


Send specific encodings (order sensitive) 


http . server . accept encoding (gzip, client) 


Send specific encodings (order sensitive) 


http . server . accept encoding . gzip (yes | no) 


Add/remove an encoding 


http . server . accept_encoding [gzip, deflate , 
identity] (yes | no) 


Add/ remove a list of encodings 


http . server . accept encoding . allow unknown 
(yes | no) 


Allow /disallow unknown encodings. 
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Table 6.4: Compression Properties 



Compression Properties 


Meaning 


http . client . allow_encoding ( identity) ; 


Allow no encodings (send uncompressed). 


http . client . allow encoding (client) ; 


Allow all client encodings. This is the default. 


http . client . allow_encoding (gzip, deflate) ; 


Allow fixed set of encodings. 


http . client . allow encoding (gzip , client); 


Allow fixed set of encodings. 


http . client . allow_encoding . gzip (yes | no); 


Add /remove one encoding 


http . client . allow encoding [gzip , deflate, 
identity] (yes | no) ; 


Add/ remove list of encodings 



Default Behavior 

By default. Blue Coat sends the client's list of the accept encoding algorithms, except for unknown 
encodings. If compression is not enabled, the default overrides any configured CPL policy. 

If Accept -Encoding request header modification is used, it is overridden by the compression 
related policy settings shown in Table 6.4. The Accept -Encoding header modification can continue 
to be used if no compression policies are applied, or if compression is not enabled. Otherwise, the 
compression-related policies override any Accept -Encoding header modification, even if the 
Accept -Encoding header modification appears later in the policy file. 

Adding encoding settings with client-side controls depend on if the client originally listed that 
encoding in its Accept -Encoding header. If so, these encodings are added to the list of candidates to 
be delivered to the client. The first cache object with an Accept -Encoding match to the client-side list 
is the one that is delivered. 

Suggested Settings for Compression 

□ If client-side bandwidth is expensive in your environment, use the following policy: 

<proxy> 

http . client . allow_encoding (client) 
http . allow_compression (yes ) 

□ If server-side bandwidth is expensive in your environment, compared to client-side bandwidth 
and CPU: 

http . server . accept_encoding (all ) 

http . server . accept_encoding . allow_unknown (no) ; default 
http . allow_compression (yes ) 
http . allow_decompression (yes) 

□ If CPU is expensive in your environment, compared to server-side and client-side bandwidth: 
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http . server . accept_encoding (client ); If no content transformation policy is 
configured 

http . server . accept_encoding ( identity) ; If some content transformation policy 
is configured 

http . allow_compression (no) ; default 
http . allow_decompression (no) ; default 

Limitations 

□ Policy-based content transformations are not stored as variant objects. If content transformation is 
configured, it is applied on all cache-hits, and objects might be compressed all the time at the end 
of such transformation if they are so configured. 

□ The variant that is available in the cache is served, even if the client requests a compression choice 
with a higher qvalue. For example, if a client requests Accept -encoding : gzip; q=l , 
deflate ; q= 0 . 1 , and only a deflate-compressed object is available in the cache, the deflate 
compressed object is served. 

□ The HTTP proxy ignores Cache-Control : no-transform directive of the OCS. To change this, 
write policy to disallow compression or decompression if Cache-Control : no-transform 
response header is present. 

□ The ProxySG treats multiple content encoding (gzip, deflate or gzip, gzip) as an unknown 
encoding. (These strings indicate the content has been compressed twice.) 

□ The gzip and deflate formats are treated as completely separate and are not converted from one to 
the other. 

□ Blue Coat recommends using gzip encoding (or allowing both gzip and deflate) when using 
the HTTP compression feature. 

□ If the ProxySG receives unknown content encoding and if content transformation is configured 
(such as popup blocking), an error results. 

□ If the origin server provides compressed content with a different compression level then that 
specified in policy, the content is not re-compressed. 

□ If the ProxySG compressed and cached content at a different compression level than the level 
specified in a later transaction, the content is not re-compressed. 

□ Parsing of container HTML pages occurs on the server side, so pipelining (prefetching) does not 
work when the server provides compressed content. 

□ Compressing a zip file breaks some browser versions, and compressing images does not provide 
added performance. For a current list of content types that are not compressed, refer to the 
Release Notes. 

□ All responses from the server can be compressed, but requests to the server, such as POST 
requests, cannot. 

□ Only 200 ok responses can be compressed. 
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Troubleshooting HTTP Proxy Issues 

This section discusses problems you might encounter using the HTTP proxy. 

Using Explicit HTTP Proxy with Internet Explorer 

Internet Explorer does not allow OCS NTLM authentication through a ProxySG when explicitly 
proxied. To correct this. Blue Coat added a Proxy-Support : Session-based-authentication 
header that is sent by default when the ProxySG receives a 401 authentication challenge from 
upstream when the client connection is an explicit proxy connection. 

For older browsers or if both the ProxySG and the OCS do NTLM authentication, the Proxy-Support 
header might not work. In this case, you can disable the header and instead enable NTLM-force, 
which converts the 401-type server authentication challenge to a 407-type proxy authentication 
challenge, supported by Internet Explorer. The ProxySG also converts the resulting 
Proxy- Authentication headers in client requests to standard server authorization headers, which 
allows an OCS NTLM authentication challenge to pass through when Internet Explorer is explicitly 
proxied through the ProxySG. 

Disabling the Proxy-Support Header 

You can control the header using header modification policy. Suppression or modification of the 
Proxy-Support custom header keeps the ProxySG from sending this default header. Use either the 
Visual Policy Manager (VPM) or CPL to disable the header through policy. For complete information 
on using VPM, see Chapter 14: "The Visual Policy Manager" on page 567. 



Note: To suppress the Proxy-Support header globally, use the http force-ntlm command to 

change the option. To suppress the header only in certain situations, continue with the 
procedures below. 



To Suppress Proxy-Support Header through VPM 

To suppress the header using VPM, create a new Web Access Layer. Then: 

1. Right click in the Action field to see the drop-down list; select Set. 

The Existing Action Object dialog displays. 

2. Click New to see the drop-down list; select Control Response Header. 
The Add Control Response Header Object dialog displays. 
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Figure 6-1 1 : Add Control Response Header Object 

3. Fill in the fields as follows: 

• Name: Enter a meaningful name. This name displays in the Existing Action Objects dialog. 

• Show: Select Custom from the drop-down list. 

• Header Name: Enter Proxy-Support. 

• Make sure the Suppress radio button is selected. 

4. Click OK. 

5. Scroll to the bottom of the Add Control Response Header Object dialog to see the Proxy-Support 
header. 

6. Click OK. 

To Suppress Proxy-Support Header through CPL 

Use CPL to define the Proxy-Support custom header object and to specify what action to take. The 
example below uses Proxy-Support as the action name, but you can choose any name meaningful to 
you. The result of this action is to suppress the Proxy-Support header 

<proxy> 

action. Proxy-Support (yes) 
define action Proxy-Support 

delete (response . x_header . Proxy- Support ) 
end action Proxy- Support 

Enabling or Disabling NTLM Authentication for Internet Explorer Clients 

The following procedure forces Internet Explorer clients explicitly-proxied through a ProxySG to 
participate in NTLM authentication. This CLI setting is global, affecting all clients. You can also use 
VPM or CPL to provide granular control for NTLM authentication. (See "To Force NTLM 
Authentication through VPM" on page 222 and "To Force NTLM Authentication through CPL" on 
page 222.) These commands should only be used if the Proxy-support header is not suitable for the 
situation. 
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Note: These procedures can only be done through the CLI. The Management Console is not 

available. 



Do one of the following (note that the default is http no force-ntlm): 

□ To force NTLM authentication for Internet Explorer clients, enter the following command at the 
(config) command prompt: 

SGOS# (config) http force-ntlm 

□ To disable NTLM authentication for Internet Explorer clients, enter the following command at the 
(config) command prompt: 

SGOS# (config) http no force-ntlm 

To view all HTTP settings, see "Viewing HTTP Settings through the CLI" on page 210. 

To Force NTLM Authentication through VPM 

To use VPM to force NTLM authentication, create a new Web Access Layer. Then: 

1. Right click in the Action field to see the drop-down list; select Set. 

The Existing Action Object dialog displays. 

2. Scroll to the Force NTLM for Server Auth static object; select it. 

3. Click OK. 

To Force NTLM Authentication through CPL 

Global configuration of NTLM authentication behavior is set through the CLI command http 
force-ntlm (the default is http no force-ntlm). The http . force_ntlm_for_server_auth ( ) CPL 
property can be used to override the global settings for a particular subset. 

To create a rule to force NTLM authentication for explicitly proxied Internet Explorer clients, first 
define the action, then define the rule. 

This example implements the following policies: 

□ All clients from the "ForceNTLM_subnet" have Force-NTLM turned on. These clients do not use 
the Proxy-Support header. 

□ Requests for all other hosts have Force-NTLM turned off. These hosts use the Proxy-Support 
header. 

define subnet ForceNTLM_subnet 
10 . 10 . 0 . 0/16 
end 

< Proxy > 

client . address=ForceNTLM_subnet http . f orce_ntlm_f or_server_auth (yes) 
http . f orce_ntlm_f or_server_auth (no) 
end 
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Configuring a SOCKS Proxy 

While SOCKS servers are generally used to provide firewall protection to an enterprise, they also can 
be used to provide a generic way to proxy any TCP/IP or UDP protocols. The ProxySG supports both 
SOCKSv4/ 4a and SOCKSv5; however, because of increased username and password authentication 
capabilities and compression support. Blue Coat recommends that you use SOCKS v5. 



Note: For Blue Coat compatibility with SOCKS clients, check with customer support. For 

information on the Permeo Premium Agent (Permeo PA), see "Using the Permeo PA 
SOCKS Client with the Blue Coat SOCKS Server" on page 227. 



Understanding SOCKS Compression 

Compression over SOCKS is supported for TCP/IP tunnels, which can compress the data transferred 
between the branch (branch proxy) and main office (concentrator proxy), reducing bandwidth 
consumption and improving latency. 

TCP tunnels are created by posting a listener on a static port for protocols that have a well-known 
port; applications that use dynamic port numbers are handled through the Endpoint Mapper proxy 
that automatically creates TCP tunnels to ports where Microsoft RPC services are running. (For 
information on using the Endpoint Mapper proxy, see "Managing the Endpoint Mapper Proxy in 
Chapter 5, Services.) 

Except for enabling the SOCKS proxy, no configuration is required on the concentrator SG appliance 
to support SOCKS compression. However, configuration is required on the branch SG appliance to 
forward data through the SOCKS gateway. You can use policy or the socks -gateway CLI options to 
enable SOCKS compression globally. Using policy, you can enable or disable compression on a 
per-connection basis on either the client side or the server side. 

If SOCKS compression is enabled and the upstream SOCKS gateway does not support it, the 
connection fails. 



Note: Enabling compression on TCP tunnels impacts performance and should be done only 

when the ProxySG is sized correctly to handle the incremental CPU load. 



In a typical deployment, you will: 

□ Create an Endpoint Mapper proxy at the remote office (the downstream proxy) that intercepts 
Microsoft RPC traffic and creates dynamic TCP tunnels. Traffic to port 135 is transparently 
redirected to this service using bridging or L4 switch or WCCP For information on creating and 
enabling an Endpoint Mapper proxy service, see "Managing the Endpoint Mapper Proxy" on 
page 165. 

□ Create any other TCP tunnel proxies you need at the remote office: SMTP, DNS, and the like. For 
information on configuring TCP tunnels, see "Managing TCP Tunneling Services" on page 175. 
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□ Create a SOCKS gateway at the remote office and enable compression for that gateway. This 
SOCKS gateway points to a SOCKS proxy located at the main office location (the upstream proxy, 
the core of the network). For information on creating a SOCKS gateway and enabling SOCKS 
compression, see "SOCKS Gateway Configuration" on page 867. 

□ Set policy to forward TCP traffic through that SOCKS gateway. You can do this through the 
<proxy> layer using either the VPM or CPL. For more information, see "Using Policy to Control 
the SOCKS Proxy" on page 226. 



Note: In cases where more than two proxies exist in the chain and intermediate proxy nodes are 

configured to do compression, the traffic is forwarded as is. If the intermediate proxy is 
not configured to do compression, traffic is decompressed before being forwarded to the 
next proxy. 



Creating and Configuring the SOCKS Service 

Complete the following steps to create a SOCKS proxy and to configure SOCKS-proxy connection and 
timeout values. 

To Create a SOCKS Proxy Server through the Management Console 
1. Select Configuration>Services>SOCKS Proxy. 



SOCKS Proxy 

















Max-Connections: 


0 


(0 means unlimited) 




Connection timeout: 


120 


seconds 




Bind timeout on accept: 


120 


seconds 




Minimum idle timeout: 


7200 


seconds (0 means unlimited) 




Maximum idle timeout: 


0 


seconds (0 means unlimited) 





Figure 6-12: SOCKS Proxy Tab 



2. Fill in the option fields (described below) as needed. The defaults are displayed and should be 
sufficient for most purposes. 



Max-Connections 


connections 


Set maximum allowed SOCKS client connections. The default 
of 0 indicates an infinite number of connections are allowed. 


Connection timeout 


seconds 


Set maximum time to wait on an outbound CONNECT. 


Bind timeout on 
accept 


seconds 


Set maximum time to wait on an inbound BIND. 


Minimum idle timeout 


seconds 


Specifies the minimum idle timeout after which SOCKS can 
consider the connection for termination when the max 
connections are reached. 


Maximum idle timeout 


seconds 


Specifies the maximum idle timeout value after which SOCKS 
should terminate the connection. 
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To Configure the SOCKS Proxy through the CLI 

1. At the (config) command prompt, enter the following commands: 

SGOS# (config) socks-proxy accept-timeout seconds | connect -timeout seconds | 
max-connections number | max- idle -timeout seconds | min-idle-timeout seconds 

2. (Optional) View the results. 

SGOS# (config) show socks-proxy 

max-connections: 0 
accept-timeout: 120 
connect-timeout : 120 
min-idle-timeout: 7200 
max- idle-timeout : 0 

Enabling the SOCKS Proxy 

Note that a SOCKS port is already configured on port 1080 and enabled. 

To Edit an Existing SOCKS Port Service through the Management Console 

1. Select Configuration>Services>Service Ports. 

2. Highlight the SOCKS server. 

3. Click Edit; the Edit Service dialog appears. 




Figure 6-13: SOCKS Add Service Dialog 

4. In the Protocol drop-down list, select SOCKS. 

5. The default IP address value is all. To limit the service to a specific IP, select the IP from the 
drop-down list. 

6. In the Port field, specify a port number; select Enable. 
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7. Click OK; Click Apply. 

To Edit an Existing SOCKS Port Service through the CLI 

1. At the (config) command prompt, enter the following commands: 

SGOS# (config) services 
SGOS# (config services) socks 

SGOS# (config services socks) enable [ip_address:] port 

2. (Optional) View the results: 

SGOS# (config services socks) view 

Port: 1080 IP: 10.9.87.85 Type: socks 

Properties: explicit, enabled 

Using Policy to Control the SOCKS Proxy 

Once the basic configuration for the SOCKS proxy has been set through the Management Console or 
the CLI, you can use policy to control the SOCKS proxy. 



Note: SOCKS compression requires that a SOCKS gateway be set up with SOCKS compression 

enabled. You can either use policy to configure a gateway for SOCKS compression, or you 
can configure SOCKS compression while you are configuring the SOCKS gateway. To 
configure the SOCKS gateway, see "SOCKS Gateway Configuration" on page 867. 



□ To use SOCKS version 5, which allows you to use a SOCKS username/password and SOCKS 
compression, you must set the version through policy. SOCKS version 4 does not support 
compression. 

• If using VPM, go to the Forwarding layer, select Source>Set Source Object>New>SOCKS Version. 

• If using CPL. enter the following: 

<proxy> client . protocol=socks 
ALLOW socks . version=5 

DENY 

□ To use SOCKS compression, you must request SOCKS compression through policy. 

• If using VPM: 

• For global outbound connections (the downstream proxy or branch office location): go to 
the Forwarding layer, select Source>Set Source Object>New>SOCKS Gateway Compression 
Object. (Request compression is enabled by default.) 

• For global inbound connections (the upstream proxy or the main office location): go to the 
Web Access Layer, select Action>New>SOCKS Compression Object. (Allow compression is 
enabled by default.) 

• If using CPL: 

• For global outbound connections (the downstream proxy or branch office location): 
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< forwards 

client .protocol=tcp socks_gateway ( socks_gateway_alias) 
socks_gateway . request_compression (yes | no | default) 

where default refers to the current configuration. 

To enable SOCKS compression on a per-connection basis, use a policy similar to the 
following: 

< forwards 

client_address =ip_address 

socks_gateway . request_compression (yes | no | default) 

• For global inbound connections (the upstream proxy or the main office location): 

<proxys 

socks .method=CONNECT socks . allow_compression (yes | no) 

Allow compression is enabled by default. 

Using the Permeo PA SOCKS Client with the Blue Coat SOCKS Server 

The Blue Coat ProxySG can be used as a SOCKS gateway by the Permeo Premium Agent (PA), with 
full licensing support and Dynamic Port Management (DPM) functionality. 

The ProxySG supports the Windows Permeo PA SOCKS client version 5.12a, including those clients 
that require the special probe license protocol and corresponding customer ID. Note that each 
ProxySG can only support PA clients with the same customer ID. 

Licensing the PA SOCKS client on the ProxySG is a two step process: 

□ Get the customer ID from the PA client. 

□ Tell the ProxySG the PA customer ID. 



Note: The default license setting for the Permeo PA client on the ProxySG is off. This setting 

should only be enabled when you are using the PA client. 



To obtain the PA Customer ID: 

1. From the PA client, launch the Permeo Agent User Properties (Start Menu>AII Programs>Permeo 
Premium Agent). 
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Figure 6-14: Permeo Premium Agent User Properties 
2. Click the About tab. 




Figure 6-15: Permeo Premium Agent About Tab 

3. Make a note of the Customer ID number, which is in hex. In the example above the Customer ID is 
1111 . 

To Validate the Permeo PA License on theProxySG: 



Note: You cannot validate the license through the Management Console. 



1. From the ProxySG, launch the CLI: 

SGOS> enable 
Enable Password: 

SGOS# configure terminal 

Enter configuration commands, one per line. End with CTRL-Z. 
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2. From the (conf ig) prompt: 

SGOS# (config) socks-proxy pa-customer- id customer_id 

where customer_idis the Customer ID number you took from the About tab on the PA 
client. 

To Disable the Permeo PA License: 

From the (config) prompt: 

SGOS# (config) socks-proxy pa -customer- id 0 

Limitations 

□ Protocol Detection interferes with SOCKS and must be disabled on the ProxySG. The CPL policy 
should include the line detect_protocol (no) . 

□ SOCKS compression should be disabled when using the PA SOCKS client. The CPL policy should 
include the line socks . accelerate (no) . 

□ The ProxySG only supports username and password authentication between the ProxySG and the 
SOCKS Permeo PA client. 

□ The ping and trace route functions from Permeo PA administrator tool are not compatible with 
this release (5.1). 

□ Proxy chaining is not supported between the ProxySG and the Permeo Application Gateway 
(ASG). 

□ The policy update feature on the PA is not supported when using the ProxySG. Note that PA can 
get policy from the PITTP source as well as the ASG so it can still do automatic updates from a 
external Web server. 

□ Only the UPWD authentication method is supported. 

Understanding Shell Proxies 

Shell proxies are those that provide a shell allowing a client to connect to the ProxySG. In this version, 

only a Telnet shell proxy is supported. 

Using a shell proxy, you can: 

□ terminate a Telnet protocol connection either transparently or explicitly. 

□ authenticate users either transparently or explicitly. 

□ view the access log. 

□ enforce policies specified by CPL. 

□ communicate though an upstream SOCKS gateway and PITTP proxy using the CONNECT 
method. 
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Within the shell, you can configure the prompt and various banners using CPL $substitutions. You 
can also use hard-coded text instead of CPL substitutions (available substitutions are listed in the table 
below). The syntax for a CPL substitution is: 

$ (CPL_property) 

Table 6.5: Substitutions Available at New Connection Time 



proxy . name or 
appliance . name 


Configured name of the ProxySG. 


proxy . address 


IP address of the appliance on which this connection is accepted. 


proxy . card 


Adapter number of the appliance on which this connection is accepted. 


client .protocol 


This is "telnet". 


client . address 


IP address of the client. 


proxy . primary address or 
appliance . primary address 


Primary address of the proxy, not where the user is connected. 


release . id 


SGOS version. 



Customizing Policy Settings for Shell Proxies 

To manage a shell proxy through policy, you can use the conditions, properties, and actions list below. 
For information on using CPL to manage shell proxies, refer to the Blue Coat ProxySG Content Policy 
Language Guide. 

Conditions: 



All time and date related triggers 


proxy . address= 


All exception related triggers 


proxy . card= 


All server url triggers 


proxy . port= 


All url triggers 


client .protocol= 


All authentication related triggers 


user-defined conditions 


category= 


client . protocol=telnet 


client . address= 


url . scheme=telnet 



Properties: 



allow, deny, force_deny 


force_exception (exception_id [ , details] ) 


action.action_name{yes |no) 


forward (alias list | no) 


All traced properties 


forward. fail open (yes | no) 


All access_logd properties 


ref lect_ip (auto | no | client | vip | ip-address) 
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All log. xxx () properties 


socks_gateway (alias_list | no) 


access_server (yes | no) 


socks_gateway . fail_open (yes | no) 


authenticate . force (yes | no) 


telnet .prompt (no | string) 


authenticate (realm) 


telnet. realm banner (no | string ) 


exception (exception_id [ , details] ) 


telnet . welcome banner (no | string) 



The banner strings support $-sign substitutions. 
Actions: 



rewrite (url . host , host regex pattern, 
replacement pattern) 


log_message ( ) 


rewrite (url, url regex pattern, 
replacement pattern) 


not if y_email (subject, body ) 


set (url_port , port_number) 


notify_snmp (message) 



Boundary Conditions for Shell Proxies 

□ A hardcoded timeout of five minutes is enforced from the acceptance of a new connection until 
destination information is provided using the Telnet command. 

□ If proxy authentication is enabled, users have three chances to provide correct credentials. 

□ Users are not authenticated until destination information is provided. 

□ Users can only enter up to an accumulated 2048 characters while providing the destination 
information. (Previous attempts count against the total number of characters.) 

□ Connection to an upstream HTTP proxy is not encouraged. 

□ If connections from untrustworthy IP address or subnet are not desired, then a 
client IP /subnet-based deny policy must be written. 

Understanding Telnet Shell Proxies 

The Telnet shell proxy allows you to manage a Telnet protocol connection to the ProxySG. Using the 

Telnet shell proxy, you can do: 

□ Explicit termination without proxy authentication, where you explicitly connect, through Telnet, 
to the ProxySG hostname or IP address. In this case, the ProxySG provides a shell. 

□ Explicit termination with proxy authentication, where after obtaining the destination host and 
port information from user, the ProxySG challenges for proxy credentials. Once the correct proxy 
credentials are provided and authenticated, the ProxySG makes an upstream connection and goes 
into tunnel mode. In this case, the ProxySG provides a shell. 
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□ Transparent termination without proxy authentication, where the ProxySG intercepts Telnet 
traffic through an L4 switch, software bridge, or any other transparent redirection mechanism. 
From the destination address of TCP socket, the ProxySG obtains OCS contact information and 
makes the appropriate upstream connection, either directly or through any configured proxy. For 
more information on configuring a transparent proxy, see "Transparent Proxies" on page 259. 

□ Transparent termination with proxy authentication, where, after intercepting the transparent 
connection, the ProxySG challenges for proxy credentials. Once the correct proxy credentials are 
provided and authenticated, the ProxySG makes an upstream connection and goes into tunnel 
mode. For more information on configuring a transparent proxy, see "Transparent Proxies" on 
page 259. 

Once in the shell, the following commands are available: 

□ help: Displays available commands and their effects. 

□ telnet <server [ -.port] >: Makes an outgoing telnet connection to specified server. The colon (:) 
between server and port can be replaced with a space, if preferred. 

□ exit: Terminates the shell session. 

Creating a Telnet Shell Proxy Service 

On a new system, Telnet proxy service is configured but disabled on port 23. On an upgrade, a Telnet 
proxy service is not created. 

To enable or create a Telnet proxy service, use Services>Service Ports on the Management Console, or 
conf ig>services>telnet from the CLI. For more information, see "Managing the Telnet Shell Proxy 
Service" on page 177. 

Customizing Welcome and Realm Banners and Prompt Settings 

You can configure banners for the Telnet shell and the realm and set the prompt that users see when 
entering the shell. 

To Customize Telnet Shell Proxy Settings through the Management Console 
1. Select Configuration>Services>Shell Proxies>Telnet Proxy Settings. 



Telnet Proxy Settings 

- Telnet Proxy Settings 

I | Limit Max Connections 

Max connections: 



View/Edit 
View/Edit 
View/Edit 

Figure 6-16: Telnet Proxy Settings 



- Banner Settings - 
Welcome banner: 

Realm banner: 
Prompt: 
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2. To set the maximum concurrent connections, select Limit Max Connections. Enter the number of 
maximum concurrent connections allowed for this service. Allowed values are between 1 and 
65535. 

3. Set the banner settings: 

a. To set the Welcome banner message (users see this when they enter the shell), click 

View/Edit next to the Welcome Banner. The Edit Welcome Banner dialog displays. (If you 
do not want this banner displayed, remove the text.) 




Figure 6-17: Editing Welcome Banner Properties. 

Change the banner as necessary. The $ (client .protocol) text is a CPL variable indicating 
that Telnet is the protocol. You do not have to use a variable. (For a list of available 
$substitutions, see "Substitutions Available at New Connection Time" on page 230.) When 
finished, click OK. Click Apply. 

b. To set the realms banner message (users see this help message just before they see the 
Username prompt for proxy authentication), click View/Edit next to the Realms Banner. The 
Edit Realms Banner dialog displays. (If you do not want this banner displayed, remove 
the text.) 



< Edit Realm Banner 



-ini xl 



Realm Banner Text: 



Enter credentials for realm $(realm) 



□K | Cancel | 

Figure 6-18: Editing Realm Banner Properties 

Change the banner as necessary. The $ (realm) text is a CPL variable indicating the name of 
the realm. You do not have to use a variable. (For a list of available substitutions, see 
"Substitutions Available at New Connection Time" on page 230.) When finished, click OK. 
Click Apply. 
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c. To set the prompt, click View/Edit next to the Prompt line. The Prompt dialog displays. 




Figure 6-19: Editing the Prompt 

Change the banner as necessary. The default is $ (client-protocol ) >, where 
$ (client-protocol) is Telnet. You do not have to use a variable. (For a list of available 
substitutions, see "Substitutions Available at New Connection Time" on page 230.) When 
finished, click OK. Click Apply. 

To Customize Telnet Shell Proxy Settings through the CLI 

You can use CPL substitutions when creating welcome and realm banners and Telnet prompts. For a 
list of available CPL substitutions, see "Substitutions Available at New Connection Time" on page 230. 

1. From the (config) prompt, enter the following commands: 

SGOS# (config) shell max-connections number 

SGOS# (config) shell welcome-banner welcome-banner-string (Enclose string in 
quotes if string includes spaces) 

SGOS# (config) shell realm-banner realm-banner-string (Enclose string in 
quotes if string includes spaces) 

SGOS# (config) shell prompt prompt-string (Enclose string in quotes if string 
includes spaces) 



where: 



max- connect ions 


number 


Allowed values are between 1 and 65535. 


welcome -banner 


string 


The text a user sees when the shell is entered. You can hide this 
banner by using shell no welcome -banner. 


realm-banner 


string 


The text a user sees when the realm is entered. You can hide this 
banner by using shell no welcome -banner. 


prompt 


string 


The prompt a user sees when the shell is entered. You can hide 
the prompt by using shell no prompt. 



2. (Optional) To view the shell settings: 
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SGOS# (config) show 
max-connections : 
prompt : 
realm-banner : 
welcome-banner : 



shell 

Unlimited 
Telnet # 

Enter credentials for realm Test 
Welcome to Blue Coat Telnet shell 



proxy 



To Hide the Shell’s Settings: 



SGOS# (config) 
SGOS# (config) 
SGOS# (config) 
SGOS# (config) 



shell 

shell 

shell 

shell 



no welcome-banner 
no realm-banner 
no prompt 

no max-connections 



Limitations for Telnet Shell Proxies 

□ Telnet credential exchange is in plaintext. 

□ A Telnet proxy cannot be used to communicate with non-Telnet servers (such as Webservers on 
port 80) because Telnet proxies negotiate Telnet options with the client before a server connection 
can be established. 



Configuring an SSL Proxy 

HTTPS traffic poses a major security risk to enterprises. Because the SSL content is encrypted, it can't 
be intercepted by normal means, allowing users to bring in viruses, access forbidden sites, or leak 
business confidential information over the HTTPS connection on port 443. 

The SSL proxy allows you to intercept HTTPS traffic (in explicit and transparent modes) so that 
security measures such as authentication, virus scanning and URL filtering, and performance 
enhancements such as HTTP caching can be applied to HTTPS content. Additionally, the SSL proxy 
allows you to validate server certificates presented by various HTTPS sites at the gateway and offers 
information about the HTTPS traffic in the access log. 



Important: An SSL proxy license is required to use the SSL proxy. For information on licensing, 
see Chapter 2: "Licensing" on page 47. 



Understanding the SSL Proxy 

The SSL Proxy can be used to tunnel or intercept HTTPS traffic. The SSL Proxy tunnels all HTTPS 
traffic by default unless there is an exception, such as a certificate error or a policy denial. In such 
cases the SSL Proxy intercepts the SSL connection and sends an error page to the user. The SSL Proxy 
allows interception of HTTPS traffic even when there are no errors. Such interception enables the 
application of various security policies to HTTPS content. 

Some HTTPS traffic, such as financial information, should not be intercepted. The SSL proxy can do 
the following operations while tunneling HTTPS traffic. 

□ Validate server certificates, including revocation checks using Certificate Revocation Lists (CRLs). 

□ Check various SSL parameters such as cipher and version. 
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□ Log useful information about the HTTPS connection. 

When the SSL Proxy is used to intercept HTTPS traffic, it can also: 

□ Cache HTTPS content. 

□ Apply HTTP-based authentication mechanism. 

□ Do virus scanning and URL filtering. 

□ Apply granular policy (such as validating mime type and filename extension). 

Validating the Server Certificate 

The SSL Proxy can do the following checks on server certificates: 

□ Verification of issuer signature. 

□ Verification of certificate dates. 

□ Comparison of hostname in the URL and certificate (intercepted connections only). 

Hostnames in server certificates are important because the SSL Proxy can identify a Web site just 
by looking at the server certificate if the hostname is in the certificate. Most content-filtering 
HTTPS sites follow the guideline of putting the name of the site as the common name in the 
server's certificate. 

□ Verification of revocation status. 

To mimic the overrides supported by browsers, the SSL Proxy can be configured to ignore failures 
for the verification of issuer signatures and certificate dates and comparision of the hostname in 
the URL and the certificate. 

The SG appliance trusts all root CA certificates that are trusted by Internet Explorer and Firefox. This 
list is updated to be in sync with the latest versions of IE and Firefox. 

Checking CRLs 

An additional check on the server certificate is done through Certificate Revocations Lists (CRLs). 
CRLs are lists that show which certificates are no longer valid; the CRLs are created and maintained 
by Certificate Signing Authorities that issued the original certificates. 

Only CRLs that are issued by a trusted issuer can be used by the SG Appliance. The CRL issuer 
certificate must exist as CA certificate on the SG Appliance before the CRL can be imported. 

The SG Appliance allows: 

□ One local CRL per certificate issuing authority. 

□ An import of a CRL that is expired; a warning is displayed in the log. 

□ An import of a CRL that is effective in the future; a warning is displayed in the log. 

Determining What HTTPS Traffic to Intercept 

The default mode of operation for the SSL Proxy is to intercept HTTPS traffic only if there is an 
exception, such as a certificate error. It tunnels all HTTPS traffic otherwise. . 
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To intercept HTTPS traffic for reasons other than error reporting many existing policy conditions, such 
as destination IP address and port number, can be used. 

Additionally, the SSL proxy allows the hostname in the server certificate to be used to make the 
decision to intercept or tunnel the traffic. The server certificate hostname can be used as is to make 
intercept decisions for individual sites, or it can be categorized using any of the various URL 
databases supported by Blue Coat. Categorization of server certificate hostnames can help place the 
intercept decision for various sites into a single policy rule. 

Recommendations for intercepting traffic include: 

□ Intercept Intranet traffic. 

□ Intercept suspicious Internet sites, particularly those that are categorized as none in the server 
certificate. 

□ Intercept sites that provide secure web based e-mail, such as Gmail over HTTPS. 

Managing Decrypted Traffic 

After the HTTPS connection is intercepted, you can do: 

□ Anti-virus scanning over ICAP. 

□ URL filtering (on box and off -box). Blue Coat recommends on box URL / Content filtering if you 
use transparent proxy. When the URL is sent off-box for filtering, only the hostname or IP address 
of the URL (not the full path) is sent for security reasons. 

□ Filtering based on the server certificate hostname. 

□ Caching. 

HTTPS applications that require browsers to present client certificates to secure Web servers do not 
work if you are intercepting traffic. Such applications should not be intercepted by creating a policy 
rule. 

If you intercept HTTPS traffic, be aware that local privacy laws might require you to notify the user 
about interception or obtain consent prior to interception. You can use the HTML Notify User object 
to notify users after interception. You can use consent certificates to obtain consent prior to 
interception. The HTML Notify User is easier; however, note that the SG Appliance has to decrypt the 
first request from the user before it can issue an HTML notification page. 

Terminology 

n Client consent certificates: A certificate that indicates acceptance or denial of consent to decrypt 
an end user's HTTPS request. 

□ Emulated certificates: Certificates that are presented to the user by ProxySG when intercepting 
HTTPS requests. Blue Coat emulates the certificate from the server and signs it, copying the 
subjectName and expiration. The original certificate is used between the ProxySG and the server. 

□ Issuer keyrings: The keyring that is used by the ProxySG to sign emulated certificates. The 
keyring is configured on the ProxySG and managed through policy. 
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□ Server Certificate Categories: The hostname in a server certificate can be categorized by BCWF or 
another content filtering vendor to fit into categories such as banking, finance, sports. 

□ SSL Interception: Decrypting SSL connections. 

□ SSL Proxy: A proxy that can be used for any SSL traffic (HTTPS or not), in either forward or 
reverse proxy mode. 

Intercepting HTTPS Traffic 

Intercepting HTTPS traffic (by decrypting SSL connections at the ProxySG) allows you to apply 

security measures like virus scanning and URL filtering. 

Configuration of the interception of HTTPS traffic requires the following steps: 

□ Determine whether you are using transparent or explicit mode. For information on explicit versus 
transparent proxies, see "About Explicit and Transparent Proxy" on page 181. 

□ Create an SSL service or HTTP / SOCKS services, depending on whether you are using transparent 
or explicit mode. For more information on creating an SSL service, skip to "Setting Up the SSL 
Proxy in Transparent Proxy Mode" on page 239. 

□ Create or import an issuer keyring, which is used to sign emulated server certificates to clients on 
the fly, allowing the SSL proxy to examine SSL content. For more information on creating an 
issuer keyring, see "Creating an Issuer Keyring for SSL Interception" on page 241. 

□ (Optional) Use the Notify User object or client consent certificates to notify users that their requests 
are being intercepted and monitored. Whether this is required depends on local privacy laws. 
Note that the ProxySG has to decrypt the first request from the user to issue an HTML notification 
page. If this is not desirable, use client consent certificates instead. For more information on 
configuring the Notify User object, see "Notify User" on page 638. For information on managing 
client consent certificates, see "Using Client Consent Certificates" on page 243. 

□ Download CA certificates to desktops to avoid a security warning from the client browsers when 
the ProxySG is intercepting HTTPS traffic. For information, see "Downloading an Issuer 
Certificate” on page 243. 

□ Using policy (VPM or CPL), create rules to intercept SSL traffic and to control validation of server 
certificates. By default, such traffic is tunneled and as long as there are no errors such as certificate 
errors or policy denials, the traffic is not intercepted. You must create suitable policy before 
intercepting SSL traffic. For more information on using policy to intercept SSL traffic, see 
"Configuring SSL Rules through Policy" on page 245. 

□ Configure the ProxyAV or other third-party ICAP vendor, if you have not already done this. For 
more information on ICAP-based virus scanning, see "Section A: ICAP" on page 512. 

□ Configure the Blue Coat Web Filter (BCWF) or a third-party URL-filtering vendor, if you have not 
already done this. For more information on configuring BCWF, see "Configuring Blue Coat Web 
Filter" on page 795. 

□ Configure Access Logging. For more information on configuring access logging, see Chapter 20: 
"Access Logging" on page 887. 
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□ To customize exception pages (in case of server certificate verification failure), see "Section D: 
Defining Exceptions" on page 712. 

Setting Up the SSL Proxy in Transparent Proxy Mode 

Proxy services are configured from the Management Console or the CLI. If using SSL proxy in 
transparent mode, continue with this section. If using SSL proxy in explicit mode, you might need an 
HTTP proxy or a SOCKS proxy. For information on configuring an SSL Proxy in explicit mode, see 
"Setting Up the SSL Proxy in Explicit Proxy Mode" on page 240. 

To Configure an SSL Service through the Management Console 

1. Select Configuration>Services>Service Ports. 

2. Click New; the Add Service dialog appears. 



Add service 




Figure 6-20: Creating an SSL Service 

3. In the Protocol drop-down list, select SSL. 

4. The default IP address value is all, and cannot be changed. 

5. Make sure the Enabled box is checked. 

6. In the Port field, specify a port number; Port 443 is the default. 

7. In the Attributes field, select Send-client-IP if required. Other values are not configurable. 



Note: The Send-client-IP attribute allows the ProxySG to pretend to be the client, allowing the 

origin content server to see the client's IP address. If an alternate path exists for traffic 
returning from the Internet to the client, the Send-client-IP attribute does not work. 
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8. Click OK; Click Apply. 

Continue with "Creating an Issuer Keyring for SSL Interception" on page 241. 

To Create an SSL Service through the CLI 

At the (conf ig) command prompt, enter the following commands: 

SGOS# (config) services 

SGOS#(config services) ssl 

SGOS# (config services ssl) create port 

SGOS# (config services ssl) attribute send-client- ip enable | disable 

SGOS# (config services ssl) enable port 

You can use a TCP Tunnel service in transparent mode to get the same functionality. A TCP tunnel 
service is useful when you have a combination of SSL and non-SSL traffic going over port 443 and you 
do not want to break the non-SSL traffic. The SSL service requires that all requests to its port be SSL. 

To View the Results 

SGOS# (config services ssl) view 

Port: 443 IP: 0.0. 0.0 Type: ssl 

Keyring : 

Properties: transparent, enabled 
Cipher suite : 

RC4 -MD5 : RC4 -SHA: DES -CBC3 -SHA : DES-CBC3 -MD5 : RC2 -CBC-MD5 : RC4 - 64 -MD5 : DES-CBC-SHA 
: DES-CBC-MD5 : EXP1024 -RC4 -MD5 : EXP1 024 -RC4 - SHA : EXP1024 -RC2 -CBC-MD5 : EXP1 024 -DES 
-CBC-SHA:EXP-RC4-MD5 : EXP-RC2 -CBC-MD5 : EXP-DES - CBC- SHA : AES12 8 - SHA : AES2 56 -SHA : + 
SSLv2 : +SSLv 

Continue with "Downloading an Issuer Certificate" on page 243. 

Setting Up the SSL Proxy in Explicit Proxy Mode 

The SSL Proxy can be used in explicit mode in conjunction with the HTTP Proxy or SOCKS Proxy. You 
must create an HTTP Proxy service or a SOCKS Proxy service and use it as the explicit proxy from 
desktop browsers. When requests for HTTPS content are sent to either a SOCKS proxy or an HTTP 
proxy, the proxies can detect the use of the SSL protocol on such connections and enable SSL Proxy 
functionality. 



Note: SSL detection is disabled by default for HTTP CONNECT, SOCKS, and TCP tunnels if 

you are running a new 4.2.2 system or you upgraded to 4.2.2 from a version other than 
4.2.1. If you use the SSL proxy in explicit proxy mode, you must enable SSL detection for 
the desired protocol. For information on enabling SSL detection with HTTP CONNECT, 
SOCKS, or TCP tunnels, see "Setting SSL Detection Parameters in Explicit Proxy Mode". 



For information on configuring a new HTTP proxy service, see "Managing HTTP Services" on 
page 168. For information on configuring a SOCKS proxy service, see "Configuring a SOCKS Proxy" 
on page 223. 

Continue with "Setting SSL Detection Parameters in Explicit Proxy Mode" and "Creating an Issuer 
Keyring for SSL Interception". 



240 



Chapter 6: Configuring Proxies 



Section A: Configuring Explicit Proxies 

Setting SSL Detection Parameters in Explicit Proxy Mode 

SSL detection is disabled by default for HTTP CONNECT, SOCKS, and TCP tunnels if you are 
running a new 4.2.2 system or you upgraded to 4.2.2 from a version other than 4.2.1. If you use the SSL 
proxy in explicit proxy mode and want to enable SSL detection, you must manually enable it for the 
desired protocol. 

To Set SSL Detection in Explicit Proxy Mode 

1. Select Configuration>Services>SSL Proxy; the SSL Proxy pane displays. 



SSL Proxy | 

|- SSL Proxy Options 
Issuer Keyring: 



default 



0 Enable SSL detection for HTTP CONNECT 
0 Enable SSL detection for SOCKS 
0 Enable SSL detection for TCP tunnels 













Apply 


nr 


Cancel 


nr 


Help 



2. Select the protocol for which you want to enable SSL detection, HTTP CONNECT, SOCKS, or TCP 
tunnels. 



Note: For example, to enable SSL protocol detection for HTTPS and SOCKS, select the HTTP 

CONNECT and SOCKS checkboxes. 



3. Click Apply. 

Creating an Issuer Keyring for SSL Interception 

The SSL proxy can emulate server certificates; that is, present a certificate that appears to come from 
the origin content server. In actuality. Blue Coat has emulated the certificate and signed it using the 
issuer keyring. By default only the subjectName and expiration from the server certificate is copied to 
the new certificate sent to the client. 
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1. You can create a new keyring, import a keyring, or select among existing keyrings. For 
information on creating a keyring, see "Creating a Keyring” on page 271. 

2. Select Configuration>Services>SSL Proxy; the SSL Proxy pane displays. 



SSL Proxy 

|- SSL Proxy Options 

Issuer Keyring: 



default 



0 Enable SSL detection For HTTP CONNECT 

0 Enable SSL detection for SOCKS 

1 | Enable SSL detection for TCP tunnels 



Figure 6-21 : Configuring an SSL Intercept Keyring 

3. From the dropdown menu, select the keyring you want to use as the issuer keyring. 

4. Click Apply. 

To configure policy, see "Configuring SSL Rules through Policy" on page 245. 



To Specify the Keyring and Detection Parameters through the CLI 

If you prefer, you can select the issuer keyring through VPM or CPL instead of creating it here. 

1 . You can create a new keyring, import a keyring, or decide which existing keyring you want to use 
for SSL interception. For information on creating a keyring, see "Creating a Keyring" on page 271. 

2. (Optional) Before you select a keyring to be the issuer keyring, you might want to view the 
existing keyrings already on the system. Note that keyrings without certificates cannot be used as 
an issuer keyring. To view existing keyrings: 

SGOS# conf t 
SGOS# (conf ig) ssl 
SGOS#(config ssl) view keyring 
KeyringID: default 

Is private key showable? yes 
Have CSR? no 
Have certificate? yes 
Is certificate valid? yes 
CA: Blue Coat SG610 

Expiration Date: Jun 26 00:07:15 2014 GMT 

Fingerprint : 7D : 2C : 1C : 29 : 43 : 69 : A1 : 3B : 52 : IB : D8 : 57 : C8 : 56 : CA : CO 
KeyringID : conf iguration-passwords-key 
Is private key showable? yes 
Have CSR? no 
Have certificate? no 

3. Select a keyring to be the issuer keyring: 

SGOS# (conf ig ssl) proxy issuer-keyring keyring_name 

4. (Optional) To enable detection of FITTP CONNECT, SOCKS, or TCP tunnel: 
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SGOS# (conf ig) ssl 

SGOS# (config ssl) proxy {http-ssl-detect {disable | enable) | socks-ssl-detect 
{disable | enable) | tcp-tunnel-ssl-detect {disable | enable) } 

To configure policy, see "Configuring SSL Rules through Policy" on page 245. 

Using Client Consent Certificates 

The SSL Proxy, in forward proxy deployments, can specify whether a client (typically a browser) 
certificate is required. These certificates are used for user consent, not for user authentication. 
Whether they are needed depends upon local privacy laws. 

With client consent certificates, each user is issued a pair of certificates with the corresponding private 
keys. Both certificates have a meaningful user-readable string in the common name field. One 
certificate has a string that indicates grant of consent something like: "Yes, I agree to SSL 
interception". The other certificate has a common name indicating denial of consent, something like: 
"No, I do not agree to SSL interception". 

Policy is installed on the ProxySG to look for these common names and to allow or deny actions. For 
example, when the string "Yes, I agree to SSL interception" is seen in the client certificate common 
name, the connection is allowed; otherwise, it is denied. 

To Configure Client Consent Certificates 

1. Install the issuer of the client consent certificates as a CA certificate. 

2. In VPM, configure the Require Client Certificate object in the Action column of the SSL Layer. 

3. Configure the Client Certificate object in the Source column to match common names. 

Downloading an Issuer Certificate 

When the SSL Proxy intercepts an SSL connection, it presents an emulated server certificate to the 
client browser. The client browser issues a security pop-up to the end-user because the browser does 
not trust the issuer used by the ProxySG. This pop-up does not occur if the issuer certificate used by 
SSL Proxy is imported as a trusted root in the client browser's certificate store. 

The ProxySG makes all configured certificates available for download via its management console. 
You can ask end users to download the issuer certificate through Internet Explorer or Firefox and 
install it as a trusted CA in their browser of choice. This eliminates the certificate popup for emulated 
certificates. 

To download the certificate through Internet Explorer, see "To Download a Certificate through 
Internet Explorer". To download a certificate through Firefox, see "To Download a Certificate through 
Firefox" on page 245. 

To Download a Certificate through Internet Explorer 



Note: You can e-mail the console URL corresponding to the issuer certificate to end users so that 

the end-user can install the issuer certificate as a trusted CA. 



1. Go to Statistics>Advanced. 
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2. Select SSL. 

3. Click Download a ProxySG Certificate as a CA Certificate; the list of certificates on the system display. 

4. Click a certificate (it need not be associated with a keyring); the File Download Security Warning 
displays asking what you want to do with the file. 




Figure 6-22: Internet Explorer Security Warning/Download File Dialog Box 

5. Click Save. When the Save As dialog box displays, click Save; the file downloads. 

6. Click Open to view the Certificate properties; the Certificate window displays. 




Figure 6-23: Install Certificate Dialog Box 

7. Click the Install Certificate button to launch the Certificate Import Wizard. 
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8. Make sure the Automatically select the certificate store based on the type of certificate radio button is 
enabled before completing the wizard; the wizard announces when the certificate is imported. 

9. (Optional) To view the installed certificate, go to Internet Explorer, Select Tools>lnternet 
Options>Contents>Certificates, and open either the Intermediate Certification Authorities tab or the 
Trusted Root Certification Authorities tab, depending on the certificate you downloaded. 

To Download a Certificate through Firefox 



Note: You can e-mail the console URL corresponding to the issuer certificate to end users so that 

the end-user can install the issuer certificate as a trusted CA. 



1. Go to Statistics>Advanced. 

2. Select SSL. 

3. Click Download a ProxySG Certificate as a CA Certificate; the list of certificates on the system display. 

4. Click a certificate (it need not be associated with a keyring); the Download Certificate dialog 
displays. 




Figure 6-24: Downloading an Issuer Certificate through the Firefox Browser 

5. Enable the checkboxes needed. Note that you should view the certificate before trusting it for any 
purpose. 

6. Click OK; close the Advanced Statistics window. 

Configuring SSL Rules through Policy 

SSL interception and access rules, including server certificate validation, are configured through 
policy — either VPM or CPL. Note that VPM is much easier to use than CPL. Use the SSL Intercept 
Layer to configure SSL interception; use the SSL Access Layer to control other aspects of SSL 
communication such as server certificate validation and SSL versions. To configure SSL rules using 
CPL, continue with "CPL and the SSL Intercept Layer" on page 250. 

This section covers the following topics: 
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□ "Using the SSL Intercept Layer" on page 246. 

□ "Using the SSL Access Layer" on page 248 

□ "Using Client Consent Certificates" 

Using the SSL Intercept Layer 

The SSL intercept layer allows you to set intercept options: 

□ "To Intercept HTTPS Content through VPM" 

□ "To Customize Server Certificate Validation through VPM" 

For a list of policy conditions, properties, and actions, see "CPL and the SSL Intercept Layer" on 
page 250. 

Note: For detailed instructions on using VPM, see Chapter 14: "The Visual Policy Manager" on 

page 567. 

To Intercept HTTPS Content through VPM 

1. Go to Configuration>Policy>Visual Policy Manager and launch VPM. 

2. From the Policy drop-down menu, select Add SSL Intercept Layer. 

3. Right-click Set in the Action column; the Set Action object displays. 

4. Click New and select SSL Intercept object; the Add SSL Forward Proxy object displays. 
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Figure 6-25: Adding an SSL Forward Proxy Object 

5. The default behavior is Do not Intercept. To allow SSL content to be examined, select the Intercept as 
HTTPS Forward Proxy radio button. When the SSL proxy intercepts HTTPS connections, it generates 
a private key and corresponding certificate dynamically. The checkboxes for Issuer Keyring, 
Hostname, Splash Text, and Splash URL all control various aspects for certificate emulation. Fill in 
the fields as follows: 

• Issuer Keyring: If you selected an issuer keyring previously, that keyring displays. If you did 
not select an issuer keyring previously, the default keyring displays. To change the keyring 
that is used as the issuer keyring, choose a different keyring from the dropdown menu. 

• Hostname: The hostname you put here is the hostname in the emulated certificate. 

• Splash Text: You are limited to a maximum of 200 characters. The splash text is added to the 
emulated certificate as a certificate extension. 

• Splash URL: The splash URL is added to the emulated certificate as a certificate extension. 

To Categorize Hostnames in Server Certificates through VPM 

1. While still in the Destination column of the SSL Intercept layer, right-click Set; the Set Destination 
Object displays. 

2. Click New and highlight Server Certificate Category object. The Server Certificate Category Object 
displays. You can change the name in the top field if needed. 
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Figure 6-26: Server Certificate Category Object. 

3. Highlight the categories and click Add. 

The categories you selected display in the left-hand column. 

4. Click OK. 

Using the SSL Access Layer 

The SSL Access layer allows you to set accessibility options: 

□ "To Intercept HTTPS Requests to Specific Sites through VPM” 

□ "To Customize Server Certificate Validation through VPM" 

For a list of the conditions, properties, and actions that can be used in the SSL Access layer, see "CPL in 
the SSL Layer" on page 252. 



Note: For detailed instructions on using VPM, see Chapter 14: "The Visual Policy Manager" on 

page 567. 



To Intercept HTTPS Requests to Specific Sites through VPM 

1. Go to Configuration>Policy>Visual Policy Manager and launch VPM. 

2. From the Policy drop-down menu, select Add SSL Access Layer. 

3. In the Action column, right-click Set; the Set Action object displays. 
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4. Click New and select Server Certificate; the Add Server Certificate object displays. 




Figure 6-27: The Add Server Certificate Object 
5. Fill in the fields as described below. Note that you can only choose one field: 

• Hostname: This is the hostname of the server whose traffic you want to intercept. After 
entering the hostname, use the drop-down menu to specify Exact Match, Contains, At Beginning, 
At End, Domain, or Regex. 

• Subject: This is the subject field in the server's certificate. After you enter the subject, use the 
drop-down menu to specify Exact Match, Contains, At Beginning, At End, Domain, or Regex. 

To Customize Server Certificate Validation through VPM 



Note: The policy property server .certificate. validate, if set, overrides the 

ssl -verify- server command for either HTTP or for forwarding hosts. 



1. Go to Configuration>Policy>Visual Policy Manager and launch VPM. 

2. From the Policy drop-down menu, select Add SSL Access Layer. 

3. In the Action column, right-click Set; the Set Action object displays. 

4. Click New and select Set Server Certificate Validation object. 
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Figure 6-28: Managing Server Certificate Validation 

5. By default, server certificate validation is enabled; to disable it, select Disable server certificate 
validation at the bottom of the dialog. 

If server certificate validation is enabled, you can determine behavior by selecting checkboxes to 
Ignore a hostname mismatch. Ignore certificate expiration, or Ignore untrusted issuer. These overrides 
mimic the overrides supported by most browsers. 

You can add server certificates to the ProxySG to allow proper validation. For more information, 
see "Importing a CA Certificate" on page 303. 

6. If you want to check the CA certificate revocation list (CRL) from a Certificate Authority, verify 
Also check certification revocation is selected. For information on using CRL, see "Checking CRLs” on 
page 236. 

CPL and the SSL Intercept Layer 



Note: VPM is much easier to use than CPL. All CPL gestures except the 

ssl . forward_proxy . server_keyring property, used only for troubleshooting, are 
also in VPM. 



The following CPL gestures can be used in the SSL Intercept layer: 



Note: No authentication-related triggers are allowed in the SSL Intercept layer. 
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Allowed Properties (allowed in the SSL Intercept layer only): 



ssl . f orward_proxy ( ) 

ssl . forward_proxy. hostname ( ) 

ssl . forward_proxy . issuer_keyring ( ) 

ssl . forward_proxy . server_keyring ( ) , 

ssl . f orward_proxy . splash_url ( ) 



ssl . f orward_proxy . splash_text ( ) 
trace . destination ( ) 
trace . request ( ) 
trace . rules ( ) 

ssl . f orward_proxy . server_keyring 
(used for troubleshooting only) 



Allowed Actions 

• log_message ( ) 

• notify_email ( ) 

Allowed Conditions 

• category 

• client . address 

• client. host 

• client . host . has_name 

• client .protocol 

• proxy . address 

• proxy . card 



• notify_snmp( ) 



• proxy. port 

• server . certificate . hostname 

• server .certificate . hostname . category 

• server . certificate . subj ect 

• server_url . * 

• url . * 



An example of using CPL to intercept SSL traffic is: 

/create list of servers to intercept 
define condition server_intercept_list 

server .certificate. hostname . category=webmail 
server .certificate. hostname=porn . com 
server .certificate. hostname . category=gambling 
server .certificate. hostname . category=none 
end condition server_intercept_list 

< SSL- Inter cept> 

; value no means tunnel, value https means intercept as forward proxy 
condition=server_intercept_list ssl . f orward_proxy (https ) 
ssl . forward_proxy (no) 



Note: For detailed instructions on using CPL, including detailed explanations of the gestures 

listed here, refer to the Blue Coat ProxySG Content Policy Language Guide. 
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CPL in the SSL Layer 

The following CPL gestures can be used in the SSL layer (called SSL Access layer in VPM): 

Allowed Actions (allowed in the SSL layer only) 



• server . certificate . 
validate (yes | no) 



• client . certificate . 
validate (yes | no) 



• server . certificate . 
validate . 
check_r evocation 
(local | no) ) 

• client . certificate . 
validate . check_ 
revocation (local | no) 



• server . certificate . 
validate . ignore 
(hostname_mismatch | 
expiration | 
untrusted _issuer) 

• client . certificate . 
require (yes) 



Allowed Conditions and Properties 



• client . connection . 
negotiated_ssl_version = 

( condition ) 

• client . certificate . common 
_name 

[ . exact | . substring | . pref 
ix | . suffix] = <string> 

• server . certificate . 
hostname [ . exact | 

. substring | .prefix| .suff 
ix] =<string> 

• server . certificate 

. hostname . category =! 
<exclusion_category_list 
> ( condition ) 

• ssl . proxy_mode= 



• client . certificate . 
common__name . regex = 
<regex> 

• client . certificate . 
subj ect [ . exact | 

. substring | .prefix| . 
suffix | 

.regex] = <string> 

• server . certificate . 
hostname . regex= 
<regex> 

• server . connection . 
negotiated_cipher = 



client .protocol= 
tunneled= 



• client . certificate . subj ect . 
dn = <X .500 DN> 

• client . certificate . subj ect . 
regex = <regex> 



• server . certificate . hostname . 
category = <category_list> 

\ 

• server . connection . negotiated 
_cipher . strength = low | 
medium | high | export 



Note: For detailed instructions on using CPL, including detailed explanations of the gestures 

listed here, refer to the Blue Coat ProxySG Content Policy Language Guide. 
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Notes 



Note: Pipelining configuration for HTTP is ignored for HTTPS requests intercepted by the SSL 

Proxy. When the SSL Proxy intercepts an HTTPS request, and the response is an HTML 
page with embedded images, the embedded images are not pre-fetched by the ProxySG. 



□ If the ProxySG and the origin content server cannot agree on a common cipher suite for 
intercepted connections, the connection is aborted. 

□ Key lengths of greater than 1024 bits are not supported. 

□ Server-Gated Cryptography and step-up certificates are treated just as regular certificates; special 
extensions present in these certificates are not be copied into the emulated certificate. Clients 
relying on SGC/ step-up certificates continue using weaker ciphers between the client and the 
ProxySG when the SSL Proxy intercepts the traffic. 

Advanced Topics 

If you use OpenSSL or Active Directory, you can follow the procedures below to manage your 
certificates. 

For OpenSSL, see "Creating an Intermediate CA using OpenSSL"; if using Active Directory, see 
"Creating an Intermediate CA using Microsoft Server 2003 (Active Directory)” on page 256. 

Creating an Intermediate CA using OpenSSL 

This section describes the certificate management when creating an intermediate CA using OpenSSL. 
The overall steps are: 

□ "Install OpenSSL " 

□ "Create a Root Certificate" 

□ "Modify the OpenSSL. cnf File " 

□ "Sign the ProxySG CSR" 

□ "Import the Certificate into the ProxySG" 

□ "Test the Configuration" 

Various OpenSSL distributions can be found at http://www.openssl.org. 

Install OpenSSL 

Once OpenSSL is installed, you must edit the openssl . cnf file and ensure the pathnames are 
correct. By default root certificates are located under ./PEM/DemoCA; generated certificates are located 
under /certs. 
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Create a Root Certificate 

In order to create a root Certificate Authority (CA) certificate, complete the following steps. 



Note: The key and certificate in this example is located at . /bin/PEM/demoCA/private/ 



1. Open a MS-DOS window, and enter: 

openssl req -new -x509 -keyout 

c : \resources\ssl\openssl\bin\PEM\demoCA\private\ 

cakey .pem -out c : \resources\ssl\openssl\bin\PEM\demoCA\private\CAcert . pem 

where the root directory for openssl is: \resources\ssl\openssl 
openssl req -new -x509 -keyout 

c : \resources\ssl\openssl\bin\PEM\demoCA\private\cakey .pem -out 
c : \resources\ssl\openssl\bin\PEM\demoCA\private\CAcert .pem 
Using configuration from C:\Resources\SSL\OpenSSL\bin\openssl.cnf 
Loading 'screen' into random state - done 
Generating a 1024 bit RSA private key 

+++++ 

+ + + + + 

writing new private key to 

' c : \resources\ssl\openssl\bin\PEM\demoCA\private\cakey . pem ' 

Enter PEM pass phrase: 

2. Type any string more than four characters for the PEM pass phrase. 

3. Enter the certificate parameters, such as country name, common name that are required for a 
Certificate Signing Request (CSR). 

The private key and root CA are now located under the directory . /PEM/DemoCA/private 

4. Create a ProxySG keyring. 

a. From the ProxySG Management Console, select Configuration>SSL>Keyrings. 

b. Click Create; fill in the fields as appropriate. 

c. Click OK. 

5. Create a CSR on the ProxySG. 

a. Select Configuration>SSL>Keyrings. 

b. Highlight the keyring you just created; click Edit/View. 

c. In the Certificate Signing Request pane, click Create and fill in the fields as appropriate. 



Note: Detailed instructions on creating a keyring and a CSR are in Chapter 7 of the Blue Coat 

ProxySG Configuration and Management Guide. They can also be found in the online help. 



6. Paste the contents of the CSR into a text file called new . pem located in the . /bin directory. 
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Modify the OpenSSL.cnf File 

Modify the opens si . cnf file to import the openSSL root CA into your browser. If you do not do this 
step, you must import he ProxySG certificate into the browser. 

1. In the openssl.cnf file, look for the string basicConstraints=CA, and set it to true. 

basicConstraints=CA: TRUE 

2. Save the openSSL . cnf file. 

Sign the ProxySG CSR 

Open a MS-DOS window and enter: 

openssl ca -policy policy_anything -out newcert.pem -in new.pem 
The output is: 

Using configuration from C:\Resources\SSL\OpenSSL\bin\openssl.cnf 
Enter PEM pass phrase: 

Check that the request matches the signature 
Signature ok 

The Subjects Distinguished Name is as follows 
countryName : PRINTABLE FR ' 

stateOrProvinceName : PRINTABLE : 'Paris' 

localityName : PRINTABLE :' Paris ' 

organizationName : PRINTABLE : ' BlueCoat ' 

organizationalUnitName : PRINTABLE : 'Security Team' 
commonName : PRINTABLE : 'proxysg.bluecoat.com' 

emailAddress :IA5STRING: 'support@bc.com' 

Certificate is to be certified until Sep 27 13:29:09 2006 GMT (365 days) 

Sign the certificate? [y/n] :y 

1 out of 1 certificate requests certified, commit? [y/n]y 
Write out database with 1 new entries 
Data Base Updated 

This signs the certificate; it can then be imported into the ProxySG. 

Import the Certificate into the ProxySG 

1. Open the file newcert . pem in a text editor. 

2. Go to the Management Console>Configuration>SSL>SSL Keyrings. 

3. Selecting the keyring used for SSL interception; click Edit/View. 

4. Paste in the contents of the newcert . pem file. 

5. Import the contents of the newcert . pem file into the CA Certificates list. 
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a. From the ProxySG Management Console, select Configuration>SSL>CA Certificates. 

b. Click Import; enter the certificate name in the CA Cert Name field. 

c. Paste the certificate, being sure to include the BEGIN CERTIFICATE — and the 

— END CERTIFICATE statements in the . /bin/PEM/demoCA/private/CAcert file. 

d. Click OK. 



Note: Detailed instructions on importing a CA certificate are in Chapter 7 of the Blue Coat 

ProxySG Configuration and Management Guide. 



Test the Configuration 

Import the root CA into your browser and construct an SSL interception policy. 

Note: Detailed instructions on constructing an SSL interception policy are in Chapter 6 of the 

Blue Coat ProxySG Configuration and Management Guide. 

You should not be prompted for any certificate warning. 

Creating an Intermediate CA using Microsoft Server 2003 (Active Directory) 

This section describes certificate management when creating an intermediate CA using Active 
Directory. 

Before you begin: 

□ Make sure the Windows 2003 system is an Active Directory server. 

□ Make sure IIS is installed. 

□ Install the "Certificate Services" through the control panel 

□ Select the mode to be Enterprise root CA. 

All certificate management is done through the browser using the following URL: 

http://@ip_server/CertSrv 

You will complete the following steps: 

□ "To Install the Root CA onto the Browser" 

□ "To Create a ProxySG Keyring and Certificate Signing Request" 

□ "To Sign the ProxySG CSR" 

□ "To Import the Certificate onto the ProxySG" 

□ "To Test the Configuration" 

To Install the Root CA onto the Browser 

1 . Connect to HTTP: / / @ip_server / CertSrv 

2. Click Download a CA Certificate. 
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3. Click Install this CA Certificate chain. 

This installs the root CA onto the browser. 

To Create a ProxySG Keyring and Certificate Signing Request 

1. From the ProxySG Management Console, go to SSL>Keyrings. 

2. Create a new keyring. For detailed instructions on creating a new keyring, see "Creating a 
Keyring" on page 271. 

3. Create a Certificate Signing Request (CSR). For detailed instructions on creating a CSR, see 
"Managing Certificate Signing Requests" on page 276. 

4. Click OK. 

To Sign the ProxySG CSR 

1. Connect to http:/ /@ip_server/ CertSrv 

2. Select the option Request a certificate. 

3. Select Submit an advanced certificate request and then Submit a certificate request by using a base 64 
encoded ... 

4. Paste the contents of the ProxySG CSR. 

5. Select the Certificate Template Subordinate Certification Authority. 

If this template does not exist, connect to the certificate manager tool on the Active Directory 
server and add the template. 

6. Click on Submit. 

7. Download the certificate (not the chain) as Base 64 encoded. 

8. Save this file on the workstation as newcert . pern . 

To Import the Certificate onto the ProxySG 

1. Open the file newcert . pern in a text editor. 

2. Go to the Management Console>Configuration>SSL>SSL Keyrings. 

3. Select the keyring that has the CSR created; click Edit/View. 

Note: Make sure this keyring is used as the issuer keyring for emulated certificates. Use policy 

or the SSL intercept setting in the Management Console or the CLI. 

4. Paste the contents of the newcert . pem file. 

5. Import the contents of the newcert . pem file into the CA Certificates list. 
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a. From the ProxySG Management Console, select Configuration>SSL>CA Certificates. 

b. Click Import; enter the certificate name in the CA Cert Name field. 

c. Paste the certificate, being sure to include the BEGIN CERTIFICATE — and the 

— END CERTIFICATE statements in the . /bin/PEM/demoCA/private/CAcert file. 

d. Click OK. 



Note: Detailed instructions on importing a CA certificate are in Chapter 7 of the Blue Coat 

ProxySG Configuration and Management Guide. 



To Test the Configuration 

Import the root CA into your browser and construct a SSL interception policy. 



Note: Detailed instructions on constructing an SSL interception policy are in Chapter 6 of the 

Blue Coat ProxySG Configuration and Management Guide. 



You will not be prompted for any certificate warning. 
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Section B: Transparent Proxies 

To use transparent proxy, you must: 

□ Configure the network to redirect client requests 

□ Create a transparent proxy service 

Configuring the Transparent Proxy Hardware 

For transparent proxy to work, you must use one of the following: 

□ ProxySG Pass-Through card 

□ ProxySG software bridge 

□ Layer-4 switch 

□ WCCP 

Configuring the Pass-Through Card for Hardware Bridging 

The Blue Coat Pass-Through card is a device that enables a bridge, using its two adapters, so that 
packets can be forwarded across it. Flowever, if the system crashes, the Pass-Through card becomes a 
network: the two Ethernet cables are connected so that traffic can continue to pass through without 
restriction. 

Configure a transparent service on the bridge's IP address just like for any other IP address, and it 
intercepts traffic as usual. 

The differences are: 

□ Forwards traffic: it does not intercept without enabling global IP packet forwarding. 

□ Proxies for requests on either adapter, so if you connected one side of the bridge to your Internet 
connection, be careful. 

Configuring the ProxySG for Software Bridging 

Blue Coat supports a software or dynamic bridge that is constructed using a set of installed adapters. 
Keep in mind the following about software bridges: 

□ The adapters must of the same type. Although the software does not restrict you from configuring 
bridges with adapters of different types (10/100 or GIGE), the resultant behavior is unpredictable. 

□ IP addresses — If any of the adapter interfaces to be added to the bridge already have IP addresses 
assigned to them, those IP addresses must be removed. 

To set up a software bridge, see "Configuring a Software Bridge" on page 93. 
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Configuring a Layer-4 Switch for Transparent Proxy 

In Transparent Proxy Acceleration, as traffic is sent to the OCS, any traffic sent on TCP port 80 is 
redirected to the ProxySG Appliances by the Layer 4 switch. The benefits to using a Layer 4 switch 
include: 

□ Built-in failover protection. In a multi-ProxySG setup, if one ProxySG fails, the Layer 4 switch can 
route to the next ProxySG. 

□ Request partitioning based on IP address instead of on HTTP transparent proxying. (This feature 
is not available on all Layer 4 switches.) 

□ ProxySG bypass prevention. You can configure a Layer 4 device to always go through the Blue 
Coat ProxySG machine even for requests to a specific IP address. 

□ ProxySG bypass enabling. You can configure a Layer 4 device to never go through the ProxySG. 

The following are generic directions for configuring transparent proxy using a Layer 4 switch and 
ProxySG Appliances. The steps to perform depend on the brand of Layer 4 switch. Refer to the Layer 
4 switch manufacturer's documentation for details. 

To Set up Transparent Proxy Using a Layer-4 Switch and the ProxySG 

From the Layer 4 switch: 

1. Configure the Layer 4 switch according to the manufacturer's instructions. 

2. Configure for global transparent cache switching (TCS). With global TCS, incoming traffic from all 
devices attached to all ports of the Layer-4 switch is redirected to the ProxySG. Assign an IP 
address, default gateway, and subnet mask to the Layer-4 switch. 

3. Configure TCS using a global policy, enabling redirection for all ports. 

4. Identify one or more ProxySG Appliances. 

5. Create a device server group. 

6. Apply the ProxySG name to the device group. 

7. Configure Ethernet interface 2. 

8. Disable the redirection policy for the port to which the ProxySG is connected. 

9. Configure Ethernet interface 4. 

10. Disable the redirection policy for the port to which the router is connected. 

11. (Optional) Configure the Layer-4 switch for server load balancing. 

12. Save the Layer-4 switch configuration. 

From the ProxySG: 
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□ Define the appropriate IP configurations per the instructions in the Installation Guide that 
accompanied the ProxySG. 

□ Test the new network configuration. 

Configuring WCCP for Transparent Proxy 

WCCP is a Cisco®-developed protocol that allows you to establish redirection of the traffic that flows 
through routers. 

The main benefits of using WCCP are: 

□ Scalability — With no reconfiguration overhead, redirected traffic can be automatically distributed 
to up to 32 ProxySG Appliances. 

□ Redirection safeguards — If no ProxySG Appliances are available, redirection stops and the router 
forwards traffic to the original destination address. 

For information on using WCCP with a Blue Coat ProxySG, see Appendix C: "Using WCCP" on page 
1087. 

Understanding IP Forwarding 

IP Forwarding is a special type of transparent proxy. The ProxySG is configured to act as a gateway. 
The gateway is configured so that if a packet is addressed to the gateway's adapter, but not to its IP 
address, the packet is forwarded toward the final destination. (If IP forwarding is turned off, the 
packet is rejected as being mis-addressed). 

By default, IP forwarding is set to off (disabled) to maintain a secure network. 

To Enable IP Forwarding through the Management Console 

1. Select Configuration>Network>Routing>Gateways. 

2. Select the Enable IP forwarding checkbox. 

3. Click Apply. 

To Enable IP Forwarding through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) tcp-ip ip- forwarding enable 



Important: When IP forwarding is enabled, be aware that all ProxySG ports are open and all the 
traffic coming through them is not subjected to policy, with the exception of the 
ports explicitly defined (Configuration> Services>Service Ports). 
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Creating a Transparent Proxy Service 

As noted earlier. Blue Coat recommends that you ignore authentication until the proxy service is 
configured and running. 

The below example uses HTTP. Note that two HTTP services are already configured and enabled on 
SGOS 4.x. 



To Create a Transparent HTTP Port Service through the Management Console 

1. Select Configuration>Services>Service Ports. 

2. Click New; the Add Service dialog appears. 



Add service 




( OK ] [ Cancel j 

Figure 6-29: HTTP Add Service Dialog 

3. In the Protocol drop-down list, select HTTP. 

4. The default IP address value is all. To limit the service to a specific IP, select the IP from the 
drop-down list. 

5. In the Port field, specify a port number; select Enable. 

6. In the Attributes field, select Transparent. 

7. Click OK; Click Apply. 



To Create a Transparent HTTP Port Service through the CLI 



At the (conf ig) command prompt, enter the following commands: 



SGOS# (config) 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 



services 
services) http 
services http) 
services http) 
services http) 



create [ip_address :] port 

attribute transparent enable 
enable [ ip_address : ] port 



[ip_address : ] port 
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Example 

SGOS# (config services http) attribute transparent enable 80 

To View the Results 

SGOS# (config services http) view 
Port: 8080 IP: 0.0. 0.0 

Properties: explicit, enabled 
Port: 80 IP: 0.0. 0.0 

Properties: transparent, enabled 



Type : http 
Type : http 
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Secure services allow you to provide the maximum security level for your enterprise. Maximum 
security is provided by using: 

D SSH (with optional RSA authentication). 

□ HTTPS instead of HTTP for secure communication over insecure channels. 

□ A method of authenticating (identifying your users) and authorizing (limiting what a user can 
do). 

Configuring secure services requires creating and using keypairs and certificates to verify trusted 
hosts. 

This chapter discusses: 

□ "HTTPS Reverse Proxy Overview" 

□ "Configuring HTTPS Reverse Proxy" 

□ "Managing the SSL Client" 

n "Configuring HTTP or HTTPS Origination to the Origin Content Server" 

□ "Advanced Configuration" 
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Section A: HTTPS Reverse Proxy Overview 

Offloading SSL processing from the origin server (referred to as HTTPS Reverse Proxy), allows a large 
number of requests to be processed very quickly from the ProxySG. 

The HTTPS Reverse Proxy implementation: 

□ Combines hardware-based SSL acceleration with full caching functionality 

□ Establishes and services incoming SSL sessions. 

□ Provides SSL v2.0, v3.0, and TLSvl protocol support. 

A common scenario in using HTTPS Reverse Proxy, which connects the client to the ProxySG, is in 
conjunction with HTTPS origination, which is used to connect the ProxySG to the origin content server 
(OCS). 

Before discussing the specifics of how a ProxySG accelerates HTTPS requests, it is important to 
understand securing data using HTTPS. There are several RFCs and books on the public key 
cryptographic system (PKCS). This discussion of the elements of PKCS is relevant to their 
implementation in SGOS. 

The key concepts to understand are: 

□ Public keys and private keys 

□ Certificates 

□ Keyrings 

□ Cipher Suites 

□ SSL client 

Public Keys and Private Keys 

The intended recipient of encrypted data generates a private/ public keypair, and publishes the public 
key, keeping the private key secret. The sender encrypts the data with the recipient's public key, and 
sends the encrypted data to the recipient. The recipient uses the corresponding private key to decrypt 
the data. 

For two-way encrypted communication, the endpoints can exchange public keys, or one endpoint can 
choose a symmetric encryption key, encrypt it with the other endpoint's public key, and send it. 



Certificates 

Two major kinds of certificates are used with SGOS: 

□ Server (SSL) Certificates 

□ Self-Signed Certificates 
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Server (SSL) Certificates 

SSL certificates are used to authenticate the identity of a server or a client. A certificate is confirmation 
of the association between an identity (expressed as a string of characters) and a public key. If a party 
can prove they hold the corresponding private key, you can conclude that the party is who the 
certificate says it is. The certificate contains other information, such as its expiration date. 

The association between a public key and a particular server is done by generating a certificate 
signing request using the server's or client's public key. A certificate signing authority (CA) verifies 
the identity of the server or client and generates a signed certificate. The resulting certificate can then 
be offered by the server to clients (or from clients to servers) who can recognize the CA’s signature. 
Such use of certificates issued by CAs has become the primary infrastructure for authentication of 
communications over the Internet. 

The Blue Coat SG trusts all root CA certificates trusted by Internet Explorer and Firefox. The list is 
updated periodically to be in sync with the latest versions of IE and Firefox. 

CA certificates installed on the Blue Coat SG are used to verify the certificates presented by HTTPS 
servers and the client certificates presented by browsers. Browsers offer a certificate if the server is 
configured to ask for one and an appropriate certificate is available to the browser. 

Self-Signed Certificates 

A self-signed certificate is a certificate that you create and authorize yourself that has no official 
guarantees or authority in the real world. It is mainly used for intranet security. 

Any server certificate can contain a common name with wildcard characters. 

Wildcard certificates during HTTPS Reverse Proxy are supported. Microsoft's implementation of 
wildcard certificates is as described in RFC 2595, allowing an * (asterisk) in the leftmost-element of the 
server's common name only. For information on wildcards supported by Internet Explorer, refer to the 
Microsoft knowledge base, article: 258858. 



Note: Another kind of certificate is called an external certificate. An external certificate is an 

X.509 certificate created outside the ProxySG for the purpose of encrypting data, such as 
access logs, with a public key on the ProxySG so that it can only be decrypted by someone 
off -box who has the corresponding private key. When you import an external certificate to 
the ProxySG, you can use it to encrypt your access logs so that only those with the 
appropriate security credential can decrypt them. See "Configuring the Upload Client" 
on page 909 for information about encrypting access logs. 



Keyrings 

A keyring contains a public /private keypair. It can also contain a certificate signing request or a 
signed certificate. 
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Cipher Suites Supported by SGOS 

A cipher suite is an object that specifies the algorithms used to secure an SSL connection. When a 
client makes an SSL connection to a server, it sends a list of the cipher suites that it supports. The 
server compares this list with its own supported cipher suites and chooses the first cipher suite 
proposed by the client that they both support. Both the client and server then use this cipher suite to 
secure the connection. 



Note: You can delete cipher suites that you do not trust. 



All cipher suites supported by the ProxySG use the RSA key exchange algorithm, which uses the 
public key encoded in the server's certificate to encrypt a piece of secret data for transfer from the 
client to server. This secret is then used at both endpoints to compute encryption keys. 

By default, the ProxySG is configured to allow SSLv2 and v3 as well as TLSvl traffic. The cipher suites 
available to use differ depending on whether you configure SSL for version 2, version 3, TLS, or a 
combination of these. 

Table 7.1 : SGOS Cipher Suites Shipped with the ProxySG 



SGOS Cipher # 


Cipher Name 


Strength 


Exportable 


Description 


1 


RC4-MD5 


Medium 


No 


128-bit key size. 


2 


RC4-SHA 


Medium 


No 


128-bit key size. 


3 


DES-CBC3-SHA 


High 


No 


168-bit key size. 


4 


DES-CBC3-MD5 


High 


No 


168-bit key size. 


5 


RC2-CBC-MD5 


Medium 


No 


128-bit key size. 


6 


RC4-64-MD5 


Low 


No 


64-bit key size. 


7 


DES-CBC-SHA 


Low 


No 


56-bit key size. 


8 


DES-CBC-MD5 


Low 


No 


56-bit key size. 


9 


EXP1024-RC4-MD5 


Export 


Yes 


56-bit key size. 


10 


EXP 1 024-RC4-SH A 


Export 


Yes 


56-bit key size. 


11 


EXP1024-RC2-CBC-MD5 


Export 


Yes 


56-bit key size. 


12 


EXP1024-DES-CBC-SHA 


Export 


Yes 


56-bit key size. 


13 


EXP-RC4-MD5 


Export 


Yes 


40-bit key size. 


14 


EXP-RC2-CBC-MD5 


Export 


Yes 


40-bit key size. 


15 


EXP-DES-CBC-SHA 


Export 


Yes 


40-bit key size. 
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Table 7.1 : SGOS Cipher Suites Shipped with the Proxy SG (Continued) 



16 


AES128-SHA 


Medium 


No 


128-bit key size. 


17 


AES256-SHA 


High 


No 


256-bit key size. 



Cipher Suite configuration is discussed in "Associating a Keyring and Protocol with the SSL Client" 
on page 292. 

Server Gated Cryptography and International Step-Up 

Due to US export restrictions, international access to a secure site requires the site negotiate 
export-only ciphers. These are relatively weak ciphers ranging from 40-bit to 56-bit key lengths, and 
are vulnerable to attack. 

Server Gated Cryptography (SGC) is a Microsoft extension to the certificate that allows the client 
receiving the certificate to first negotiate export strength ciphers, followed by a re-negotiation with 
strong ciphers. Netscape has a similar extension called International Step-up. 

The Proxy SG supports both SGC and International Step-up in its SSL implementation. There are, 
however, known anomalies in Internet Explorer's implementation that can cause SSL negotiation to 
fail. Refer to the following two documents for more detail and check for recent updates on the 
Microsoft support site. 

http : / /support . microsof t . com/ support /kb/articles/Q24 9/ 8/63 .ASP 
http : / /support . microsof t . com/ support /kb/articles/Q244/3/ 02 . ASP 

To take advantage of this technology, the ProxySG supports VeriSign's Global ID Certificate product. 
The Global ID certificate contains the extra information necessary to implement SGC and 
International Step-up. 



Note: When requesting a Global ID certificate, be sure to specify bluecoat as the server. 



Understanding SSL Client 

The SSL client is used to determine the protocol of outgoing HTTPS connections. The protocol must be 
specified when a ProxySG obtains content from the origin server using an encrypted connection. 

The ProxySG uses one SSL client. The role of the SSL client is to: 

□ Determine which certificate can be presented to origin servers by associating a keyring with the 
SSL client. 

□ Identify the protocol version the ProxySG uses in negotiations with origin servers. 

□ Identify the cipher suites used. 
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Section B: Configuring HTTPS Reverse Proxy 

To configure HTTPS Reverse Proxy, complete the following tasks: 

□ Create a keyring. A default keyring is shipped with the system and is used for accessing the 
management console. Create other keyrings for each SSL service. (See "Creating a Keyring" on 
page 271.) 



Note: You can also import keyrings. For information on importing keyrings, see "Importing an 

Existing Keypair and Certificate" on page 300. 



□ (Optional) Create Certificate Signing Requests (CSRs) that can be sent to Certificate Signing 
Authorities (CAs). 

□ Import server certificates from CA authorities for external use and associate them with the 
keyring. (See "Managing Server (SSL) Certificates" on page 279.) 

-or- 

CI Create certificates for internal use and associate them with the keyring. (See "Deleting an Existing 
Keyring and Certificate" on page 275.) 

□ (Optional, if using server certificates from CA authorities) Import Certificate Revocation Lists 
(CRLs) so the ProxySG can verify that certificates are still valid. 

□ Create the HTTPS Service. The keyring should contain the server certificate to present to clients 
connecting to this service. For general information on enabling services, see Chapter 5: 
"Managing Port Services" on page 151. For specific information on enabling the HTTPS Service, 
see "Managing the HTTPS Reverse Proxy" on page 169.) 



Note: If connections will be forwarded upstream using HTTPS, you can configure the SSL client 

appropriately. You can also set the SSL configuration timeout period, if the default is not 
satisfactory. For information on managing the SSL client, see "Managing the SSL Client" 
on page 291. 



Do these steps in order. 



Note: These steps must be done with a serial console or SSH connection. 



Before you begin, you should be familiar with the following terms: 



CA Certificates 



This is a certificate that has been given out by a CA identifying the authority and what 
public key to use to verify certificates signed by them. CA certificates are used to verify 
certificates presented by clients during HTTPS Reverse Proxy or to verify certificates 
presented by servers during HTTPS origination. 

You only need this certificate if the ProxySG is obtaining data through an encrypted 
source. 
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CA-Certificate 

Lists 


CA-Certificate lists allow you to associate a specific CA certificate (or a list of CA 
certificates) with the HTTPS service you create. 


Certificates 


Regular certificates are presented by the ProxySG as server certificates when doing 
HTTPS Reverse Proxy or as client certificates when doing HTTPS origination. 

A certificate can be created (self-signed) or imported from another machine. Certificates 
and CA Certificates are imported differently on the ProxySG and have different purposes. 


Certificate Signing 
Authority (CA) 


CAs receive Certificate Signing Requests and create certificates from the information and 
the keypair provided. The certificate is then returned to the originator, who can import it 
into the ProxySG. 


Certificate Signing 
Request (CSR) 


CSRs are used to send a keypair and critical information to a Certificate Signing 
Authority. You can use Blue Coat to create a CSR or you can create a CA Certificate 
off-line. 

The CSR is then sent to a Certificate Signing Authority, which provides a signed 
certificate after verifying the requester's identity. 


Certificate 
Revocation List 
(CRL) 


CRLs are lists that show which certificates are no longer valid; the CRLs are created and 
maintained by Certificate Signing Authorities. 

Only CRLs that are issued by a trusted issuer can be verified by the ProxySG successfully. 
The CRL can be imported only when the CRL issuer certificate exists as CA certificate on 
the ProxySG. 


SSL Client 


Only one SSL client can be used on the ProxySG, and only one keyring can be associated 
with it. If a keyring is associated with the SSL client and you change the association, the 
old association is overwritten by the new. 


HTTPS Service 


A service on which the ProxySG listens for Web requests sent through the HTTPS 
protocol. 


Keyring 


A keyring holds a public and private keypair, and can be used when configuring secure 
connections on the ProxySG. When a keyring is created, it only contains a keypair. You 
can associate a certificate with this keyring. If you have multiple certificates, you can 
configure multiple keyrings and associate the certificates and the keyrings. 



Creating a Keyring 

The ProxySG ships with two keyrings already created: 

□ default 

□ conf iguration-passwords-key 

The default keyring contains a certificate and an automatically-generated keypair. The default key is 
intended for securely accessing the ProxySG management console. Create an additional keyring for 
each HTTPS service defined. 



Note: A keyring is not re-usable. If you use multiple certificates, you must create multiple 

keyrings. 
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You must associate a keyring with the SSL client if the ProxySG is obtaining content through HTTPS 
from an origin content server (OCS) that requires a client certificate to be presented. If the OCS 
requires a client certificate and no keyring is associated with the SSL client, the connections fails. For 
information on associating a keyring with the SSL client, "Managing the SSL Client" on page 291. 

The conf iguration-passwords-key keyring contains a keypair but does not contain a certificate. It is 
a keyring created for encrypting passwords in the show conf ig command and should not be used for 
other purposes. 

To Create a Keyring through the Management Console 

1. Select Configuration>SSL>Keyrings>SSL Keyrings; the SSL Keyrings tab displays. 



SSL Keyrings 

- Keyrings: 

Keyring Show Encoding Cert CSR 

Keyringll9 l yes |PKCS#7 lyes I no 

configuration.. .|yes |PKCS#7 |no |no 




Create ] [ Edit/View ] [ Delete 



Figure 7-1 : SSL Keyring Tab 



2. Click Create; the Create Keyring dialog appears. 




Figure 7-2: Create Keyring Dialog 
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3. Fill in the dialog window as follows: 

• Keyring Name: Give the keyring a meaningful name to you. 

Note: Spaces in keyring names are not supported. Including a space can cause unexpected 

errors while using such keyrings. 

• Select the show option you need: 

• Show keypair allows the keys, and everything in the keys, to be exported. 

• Do not show keypair prevents the keypair from being exported. 

• Show keypair to director is a keyring viewable only if Director is issuing the command using 
a SSH-RSA connection. 



Note: The choice of show/show-director / no-show has implications for whether keyrings 

are included in profiles and backups created by Director. For more information, refer 
to the Blue Coat Director User Guide. 



• Select the key length in the Create a new -bit keyring field. A length of 1024 bits is the 

maximum (and default). Longer keyrings provide better security, but with a slight 
performance expense on the ProxySG. Be aware that the maximum key length allowed for 
international export might be different than the default. For deployments reaching outside the 
U.S., determine the maximum key length allowed for export. 

Click OK. The keyring is created with the name you chose. It does not have a certificate 
associated with it yet. To associate a certificate, see "Associating a Keyring and Protocol with 
the SSL Client" on page 292 

-or- 

• Select the Import keyring radio button. 

The grayed-out Keyring field becomes enabled, allowing you to paste in an already existing 
private key. The certificate associated with this private key must be imported separately. For 
information on importing a certificate, see "Deleting an Existing Keyring and Certificate" on 
page 275. 

If the private key that is being imported has been encrypted with a password, select Keyring 
Password and enter the password into the field. 



Note: The only way to retrieve a keyring's private key from the ProxySG is by using 

Director or the command line — it cannot be exported through the management 
console. 



4. Click OK. 
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To View or Edit a Keyring through the Management Console 

1. Select Configuration>SSL>Keyrings>SSL Keyrings; the SSL Keyrings tab displays. 

2. Click View/Edit; the Create Keyring dialog appears. 

To Create an SSL Keyring through the CLI 

At the (conf ig) command prompt, enter the following commands to create an SSL keyring: 
SGOS# (conf ig) ssl 

SGOS# (config ssl) create keyring {show | show-director | no-show} keyring_id 
[ key_length ] 



where: 



show | 

show- director 
| no-show 


• show: Allows the keys, and everything in the keys, to be exported. 

• show- director: Prevents the keypair from being exported. 

• no - show: A keyring viewable only if Director is issuing the command using a 
SSH-RSA connection. 

Note: The choice of show/show-director/no-show has implications for 
whether keyrings are included in profiles and backups created by Director. For 
more information, refer to the Blue Coat Director User Guide. 


keyring id 


The name, meaningful to you, of the keyring. 


key length 


Longer keypairs provide better security, but with a slight performance expense 
on the ProxySG appliance. The default key length used in SGOS and most 
US-based servers is 1024, which is the maximum key length. Be aware that the 
maximum key length allowed for international export might be different than the 
default. For deployments reaching outside of the US, determine the maximum 
key length allowed for export. 



To View the Results of a New Keyring through the CLI 



Note: This example shows the default keyring. 



SGOS# (config ssl) view keyring 
KeyringID: default 

Is private key showable? yes 
Have CSR? no 
Have certificate? yes 
Is certificate valid? yes 
CA: Blue Coat SG110 

Expiration Date: Dec 16 22:37:30 2013 GMT 

Fingerprint : AA: E2 : 34 : DB : 5D : 06 : A7 : FF : D8 : 6 9 : BE : 0D : 12 : FC : 34 : D5 
KeyringID : conf iguration-passwords-key 
Is private key showable? yes 
Have CSR? no 
Have certificate? no 



274 



Chapter 7: Using Secure Services 



Section B: Configuring HTTPS Reverse Proxy 



To View a Keypair 



Note: This example shows the default keypair, unencrypted. 



SGOS# (config ssl) view keypair [des | des3 | unencrypted] [keyring_id] 
[ password ] 

BEGIN RSA PRIVATE KEY 

MIICWwIBAAKBgQC6t/IhFTYuyczvEN/wT4dcJ13Ar/aEKs/CjL9DPG+ND79sscFe 
tf zmLr j BvxJmZYnim6VEMtKb0qH3 7YQjXwtQFqYAdWe+yKS6kqJ+Rky/mgHX8awL 
RvijFlBkLYMG2SOalYphOTg/v/dPm28TyJ5ZcavM5Atdpa+RRGPPDRlYQwIDAQAB 
AoGAE4TVL/Yqsttvq/Ikptd5e/2awWDjsU9UZq8V825m7uUdirxOTZtSs7FgqQhT 
YRbuQhOpOqbhcl6ihetza8sswGXJe7YYF7d2zQAfwDsvSTcsVulmXQmdhddItGuv 
+nZWVMqP/tQIk/NtRhp6I J2qg4Mu3yEVfDEeHPlUm2nGPbECQQDltYIaoiLW27sa 
+07Rzl2geVoVvdR0j KgOgOgyT65tRCgqyGv6AXIl+gWllTcP5rh01B9XX3iOwiUp 
He j KsompAkEA0BbQNCRXUXZTPyK6R6 JaHEO Ji8SSXtLCUN9RZrChdj Gc263D6/IV 
/ j qpqkLLR2qSibmKDXlADmYAP9U18ta+CwJAecPBd8TCmwpXIHEch3LRBqPNMQEz 
bX/6GfwNZT3/xEQAlszvD9N8a0hhfgqL6Y3v3Rd/lZ0yKv9PG4CTSf9iIQJAL7Jq 
+uixkxyaLEibhj vyh7Yoz/ 64xj 9tBviJQg60k/b/S2NjGzwcSm/L4Bj 7WllURXlf 
6Y0iISrEN915Rj ZuzQJAYUlytdC j 7pM2nziy07 j rWnY8MmIod3+kHlQaj 0 V/OI 6 Q 
Z5gaJ2nLOwicSlSY4MFewHavvRS18yI9 JP2ql+6Y/g== 

END RSA PRIVATE KEY 



Notes 

□ If you want to view the keypair in an encrypted format, you can optionally specify des or des 3 
before the keyring_id, along with an optional password. If the optional password is provided on 
the command line, the CLI does not prompt for a password. You can also use "" to specify an 
empty password to make the command non-interactive. 

□ If the optional password is not provided on the command line, the CLI asks for the password 
(interactive). If you specify either des or des3, you are prompted. 

□ To view the keypair in unencrypted format, select either the optional keyring_id or use the 
unencrypted command option. 

□ You cannot view a keypair over a Telnet connection because of the risk that it could be 
intercepted. 

Deleting an Existing Keyring and Certificate 

To Delete a Keyring and the Associated Certificate through the Management Console 

1. Select Configuration>SSL>Keyrings>SSL Keyrings. 

2. Highlight the name of the keyring that you want to delete. 

3. Click Delete. 

The Confirm delete dialog appears. 

4. Click OK in the Confirm delete dialog. 
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To Delete a Keyring and the Associated Certificate through the CLI 

From the (config) prompt, enter the following commands: 

SGOS# (conf ig) ssl 

SGOS# (config ssl) delete keyring keyring_id 

Managing Certificate Signing Requests 

While you must create certificate signing requests (CSR) to get a certificate signed by a Certificate 
Authority, CSRs are also used for the configuration of certificates that are sent out to clients or servers 
for external validation. 

Creating a CSR 

To Create a CSR through the Management Console 

1. Select Configuration>SSL>SSL Keyrings; click Edit/View. 

2. From the drop-down list, select the keyring for which you need a signed certificate. 

3. From the Certificate Signing Request tab, click the Create button. 

The Create Certificate-signing-request dialog displays. 




Figure 7-3: Create Certificate-Signing-Request Dialog 
4. Fill in the fields as appropriate: 

• State/Province — Enter the state or province where the machine is located. 

• Country Code — Enter the two-character ISO code of the country. 

• City/Locality — Enter the city. 

• Organization — Enter the name of the company. 

• Unit — Enter the name of the group that is managing the machine. 

• Common Name — Enter the URL of the company. 
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• Challenge — Enter a 4-16 character alphanumeric challenge. 

• E-mail Address — The e-mail address you enter must be 40 characters or less. A longer e-mail 
address will generate an error. 

• Company — Enter the name of the company. 

5. The Create tab displays the message: Creating .... 

6. Click OK. 

To Create a CSR through the CLI 

You have a choice of using the interactive or non-interactive create command. 

Note: Director uses non-interactive commands in profiles and overlays to create certificate 

signing requests. 

For more information on Director, refer to the Blue Coat Director Configuration and 
Management Guide.) 



To create a CSR using the: 

□ interactive create signing-request command: continue with the next section. 

□ non-interactive create signing- request command: skip to "To Create a Signing Request 
Non-interactively Using Create Commands" on page 278. 

To Create a CSR Interactively using Create Commands 

1. At the (config) command prompt, enter the following commands to create an SSL CSR: 
SGOS# (conf ig) ssl 

SGOS# (config ssl) create signing-request keyring_id 

Country code [] : US 

State or province [] : CA 

Locality or city [] : SV 

Organization name [] : Blue Coat 

Organization unit [] : Docs 

Common name [] : www.bluecoat.com 

Email address [] : test@bluecoat.com 

Challenge [] : test 

Company name [] : Blue Coat 

ok 



where: 



Country code 


At the country code prompt, enter the two-character ISO code of the 
country. 


State or province 


Name of the state or province where the machine is located. 


Locality or city 


Name of the town where the machine is located. 


Organization name 


Name of the company. 
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Organization unit 


Name of the group within the company. 


Common name 


Verify the Common name is the same as the domain name of the Web 
site being terminated. If the Common name and site domain name do 
not match, a client browser generates a warning whenever the 
ProxySG terminates an HTTPS request for that site. The use of 
wildcards is supported in the Common name. 


Email address 


The e-mail address you enter must be 40 characters or less. A longer 
e-mail address generates an error 


Challenge 


At the challenge prompt, enter a 4-16 character alphanumeric secret. 


Company name 


Name of the company. 



2. View the results. 

SGOS# (config ssl) view signing-request keyring_id 
BEGIN CERTIFICATE REQUEST 

MIIBVDCCAQ4CAQAwgYcxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTELMAkGAlUEBxMCUlYxEjAQ 
BgNVBAoTCUJsdWUgQ29hdDENMAsGAlUECxMERG9jczEZMBcGAlUEAxMQd3d3LmJsdWVjb2F0LmN 
vbTEgMB4GCSqGSIb3DQEJARYRdGVzdEBibHVlY29hdC5jb20wTDANBgkqhkiG9w0BAQEFAAM7AD 
A4Aj EAobHj KOAsnKVOTcsntWCdf TaNyCgwNDXf fxT5FwM0xkzQi0pCSku2 7CJXn7TahrKRAgMBA 
AGgMTAUBgkqhkiG9wOBCQcxBxMFdGVzdAAwGQYJKoZIhvcNAQkCMQwWCkJsdWUgQ29hdAAwDQYJ 
KoZIhvcNAQEEBQADMQBooZf EnzZT2WMMiu3oT9EP3CdtddOTtdBImWUXPdHJGfmlvEJ7HIOcEOW 
7 1 JP6pUY= 

END CERTIFICATE REQUEST 

To Create a Signing Request Non-interactively Using Create Commands 

At the (config) command prompt, enter the following commands to create a signing request: 
SGOS# (config) ssl 

SGOS# (config ssl) create signing-request keyring_id [ attribute_value ] 

[ attribute_value ] 

where the following attribute and value pairs are accepted: 

Mandatory: 

• cn common_name 

• challenge at_least_four_characters 

Optional: 

• c 2_character_country_code 

• o organization_name 

• ou organizational_un.it 

• email e-mail_id 

• state state or province 

• city locality or city 

• company company_name 

Notes: 
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□ If you do not specify any attributes, the interactive mode is assumed, meaning that the CSR 
cannot be created by Director in profiles or overlays. 

□ The name of the attribute is predefined and the value of the attribute is a string. The value can be 
quoted if it contains white space or other special characters. 

□ You must specify the name and value together; the order of appearance of multiple name value 
pairs does not matter. If you omit an attribute, an empty string is assumed for the value of the 
attribute. 

Example: 

# (config ssl) create signing- request keyring_id cn bluecoat challenge test 
c US state CA company bluecoat 

Viewing a Certificate Signing Request 

The main reason to view a certificate signing request is so that it can be copied for submission to the 
Certificate Signing Authority. You can view the certificate signing request either through the 
Management Console or the CLI. 

To View a Certificate Signing Request through the Management Console 

1. Select Configuration>SSL>SSL Keyrings. 

2. Click Edit/View; the SSL Certificates pane displays. 

3. From the drop-down list, select the keyring for which you have created a certificate signing 
request. 

The certificate signing request displays in the Certificate Signing Request window and can be 
copied for submission to a Certificate Signing Authority. 

To View a Certificate Signing Request through the CLI 

At the (config) command prompt, enter the following commands to create a signing request: 

SGOS# (config) ssl 

SGOS# (config ssl) view signing-request keyring_id 

The certificate signing request displays and can be copied for submission to a Certificate 
Signing Authority 

Managing Server (SSL) Certificates 

Server (SSL) certificates can be obtained two ways: 

□ Created on the ProxySG as a self-signed certificate 

□ Imported after receiving the certificate from the signing authority 

If you plan to use server (SSL) certificates (issued by well-known Certificate Authorities), you can 
obtain the keypair and Certificate Signing Requests (CSRs) off box and send them to the Certificate 
Authority for signing. You can also create self-signed SSL certificates for internal use. 
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Once the signed request is returned to you from the CA, you can import the certificate into the 
ProxySG. To create a Blue Coat CSR, see "Creating a CSR" on page 276. 



Note: If you have a CA certificate that is not on the ProxySG default CA certificate list, you 

might receive the following message when attempting to connect to a Web site: 

Network Error (ssl_failed) 

A secure SSL session could not be established with the Web Site:. 

You must import the CA Certificate before the ProxySG can trust the site. 



To create a SSL self-signed certificate on the ProxySG using a Certificate Signing Request, continue 
with the next section. 



Note: You can also create a self-signed certificate just by pressing the Create button on the 

Configuration>SSL>Keyrings>Edit/View pane. 



To import an SSL Certificate, skip "Importing a Server Certificate" on page 284. 

Creating Self-Signed SSL Certificates 

The ProxySG ships with a self-signed certificate, associated with the default keyring. Only one 
certificate can be associated with a keyring. If you have multiple services, you require one keyring for 
each certificate. 

Adding a Self-Signed SSL Certificate 

Self-signed certificates are generally meant for intranet use, not Internet. 

To Create a Self-Signed Certificate through the Management Console 

1. Select Configuration>SSL>Keyrings>SSL Keyrings; the SSL Keyrings tab displays. 

2. Highlight the keyring for which you want to add a certificate. 

3. Click Edit/View in the Keyring tab. 

The SSL Certificate dialog displays. 
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SSL Certificates 



m 



Keyring: 



Subject: 

Issuer: 

Valid from: 
Valid to: 

Certificate 



Create 



Import 



Delete 



Certificate Signing Request 



Create 



Import 

Delete 



Close 



Figure 7-4: Create Certificate Dialog 

4. Click Create to Create a Certificate; the Create Certificate dialog displays. 



Create Certificate 






Create Certificate 

State/Province: 

City/Locality: 

Organization: 

Unit: 

Common Name: 
E-mail Address: 
Company: 



Country Code: | 



Challenge: | 



OK | Cancel | 

Figure 7-5: Creating a Certificate 
5. Fill in the fields as appropriate: 
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• State/Province — Enter the state or province where the machine is located. 

• Country Code — Enter the two-character ISO code of the country. 

• City/Locality — Enter the city. 

• Organization — Enter the name of the company. 

• Unit — Enter the name of the group that is managing the machine. 

• Common Name — A common name should be the one that contains the URL with client access 
to that particular origin server. 

• Challenge — Enter a 4-16 character alphanumeric challenge. 

• E-mail Address — The e-mail address you enter must be 40 characters or less. A longer e-mail 
address will generate an error. 

• Company — Enter the name of the company. 

6. The Create tab displays the message: Creating 

To Create a Self-Signed SSL Certificate through the CLI 

You can create a self-signed certificate two ways: interactively or non-interactively. 

Note: Director uses non-interactive commands in profiles and overlays to create self-signed 

certificates. 



To create a certificate using the: 

□ interactive version of the create certificate command: continue with the next section. 

□ non-interactive version of the create certificate command: skip to "To Create a Self-Signed 
SSL Certificate Non-interactively Using Create Commands" on page 283. 



Note: If you want the certificate to be part of a profile or overlay, the keyring must be configured 

as showable. 



To Create a Self-Signed SSL Certificate Interactively Using Create Commands 

1. At the (config) command prompt, enter the following commands to interactively create a 
self-signed certificate. 

SGOS# (config ssl) create certificate keyring_id 

Country code [] : US 

State or province [] : CA 

Locality or city [] : SV 

Organization name [] : Blue Coat 

Organization unit [] : Docs 
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Common name [] : www.bluecoat.com 
Email address [] : test@bluecoat . com 
Challenge [] : test 
Company name [] : Blue Coat 
ok 



where: 



Country code 


At the Country code prompt, enter the two-character ISO code of the 
country. 


State or province 


Name of the state or province where the machine is located. 


Locality or city 


Name of the town where the machine is located. 


Organization name 


Name of the company. 


Organization unit 


Name of the group within the company. 


Common name 


Verify the Common name is the same as the domain name of the Web site 
being terminated. If the Common name and site domain name do not 
match, a client browser generates a warning whenever the ProxySG 
terminates an HTTPS request for that site. The use of wildcards is 
supported in the Common name. 


Email address 


The e-mail address you enter must be 40 characters or less. A longer 
e-mail address will generate an error 


Challenge 


At the Challenge prompt, enter a 4-16 character alphanumeric secret. 


Company name 


Name of the company. 



2. View the certificate. 

SG0S# (config ssl) view certificate keyring_id 
BEGIN CERTIFICATE 

MIIB3zCCAZmgAwIBAgIBADANBgkqhkiG9wOBAQQFADCBhzELMAkGAlUEBhMCWMxCzAJBgNVBAgT 

AkNBMQswCQYDVQQHEwJTVj ESMBAGAlUEChMJQmxlZSBDb2F0MQ0wCwYDVQQLEwREb2NzMRkwFwY 

DVQQDExB3d3cuYmxlZWNvYXQuY29tMSAwHgYJKoZIhvcNAQkBFhF0ZXN0QGJsdWVjb2F0LmNvbT 

AeFw0wMzAzMDQyMTA2NThaFw0wMzA0MDMyMTA2NThaMIGHMQswCQYDVQQGEwJVUzELMAkGAlUEC 

BMCQ0ExCzAJBgNVBAcTAlNWMRIwEAYDVQQKEwlCbHVlIENvYXQxDTALBgNVBAsTBERvY3MxGTAX 

BgNVBAMTEHd3dy5ibHVlY29hdC5jb20xIDAeBgkqhkiG9w0BCQEWEXRlc3RAYmxlZWNvYXQuY29 

tMEwwDQYJKoZIhvcNAQEBBQAD0wAw0AIxAK+AGYRMbnjyGr7U0oZUYdsl06y8uQnxq2PV6qCr4Q 

BpNlVqyrlFi7ZEaw01yMs5FwIDAQABMA0GCSqGSIb3DQEBBAUAAzEAe8zoYW0igTcGRGG7sBpca 

U95 J907ZVm8qSU/PQfxlIrDzKdRSQPO9GslI8MqXi0D 

END CERTIFICATE 

To Create a Self-Signed SSL Certificate Non-interactively Using Create Commands 



Note: If you want the keyring to part of an overlay or profile, the keyring must be configured as 

showable. 



At the (config) command prompt, use the following syntax to create a self-signed certificate 
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SGOS# (config ssl) create certificate keyring-id [ attribute_value ] 
[ attribute_value ] 

where any or all of the following attribute and value pairs are accepted: 

Mandatory: 

• cn common_name 

• challenge at_least_four_characters 

Optional: 

• c 2_character_country_code 

• o organization_name 

• ou organizational_un.it 

• email e-mail_id 

• state state or province 

• city locality or city 

• company company_name 



Notes: 

□ If you do not specify any attributes, the interactive mode is assumed, meaning that the self-signed 
certificate cannot be created by Director in profiles or overlays. 

□ The name of the attribute is predefined and the value of the attribute is a string. The value can be 
quoted if it contains white space or other special characters. 

□ You must specify the name and value together; the order of appearance of multiple name value 
pairs does not matter. If you omit an attribute, an empty string is assumed for the value of the 
attribute. 

Example: 

SGOS# (config ssl) create certificate keyring-id cn bluecoat challenge test 
c US state CA company bluecoat 

Importing a Server Certificate 

A server certificate is sent to you by a Certificate Signing Authority after receiving the Certificate 
Signing Request. The certificate request is created either off box or with the signing request you 
created through the SSL >Keyrings tab. To create an SSL signing request, follow the instructions in 
"Creating a CSR" on page 276. After the server certificate is signed by a Certificate Signing Authority 
and returned, it can be imported by completing the steps below. 

To Import a Server Certificate 

1. Copy the certificate to your clipboard. Be sure to include the "Begin Certificate" and "End 
Certificate" statements. 

2. Select Configuration>SSL>Keyrings; the SSL Keyrings tab displays. 

3. Highlight the keyring for which you want to import a certificate. 
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4. Click Edit/View in the Keyrings tab. 
The SSL Certificates pane displays. 




Figure 7-6: SSL Certificates Pane 



5. In the certificate panel, click Import. 

The Import Certificate dialog displays. 



Import Certificate-signing-request 



I mport Certif icate-signing-request 



OK | Cancel | 

Figure 7-7: SSL Import Certificate Dialog 

6. Paste the certificate you copied into the dialog box. Click OK. 
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The certificate should display in the SSL Certificates Pane, associated with the keyring you 
selected earlier. 

Using Certificate Revocation Lists 

A revocation check on the server certificate is done through Certificate Revocations Lists (CRLs). 
CRLs are lists that show which certificates are no longer valid; the CRLs are created and maintained 
by Certificate Signing Authorities. 

Only CRLs that are issued by a trusted issuer can be verified by the ProxySG successfully. The CRL 
can be imported only when the CRL issuer certificate exists as CA certificate on the ProxySG. 

The ProxySG allows: 

□ one local CRL list per certificate issuing authority. 

□ an import of a CRL that is expired; a warning is displayed in the log. 

□ an import of a CRL that is effective in the future; a warning is displayed in the log. 

CRLs can be used for the following purposes: 

□ Checking revocation status of client and / or server certificates with HTTPS Reverse Proxy. 

□ Checking revocation status of server certificates with SSL proxy. (For more information on using 
CRLS with the SSL proxy, see "Configuring an SSL Proxy" on page 235.) 

□ ProxySG-originated HTTPS downloads (secure image download, content filter database 
download, and the like). 

PEM-encoded CRLs are supported for inline cut-and-paste imports via the CLI or Management 
Console. DER-format (binary) CRLs are supported if downloaded from a URL. 

To Import a CRL 

You can choose from among four methods to install a CRL on the ProxySG through the Management 
Console: 

□ Use the ProxySG Text Editor, which allows you to enter the installable list (or copy and paste the 
contents of an already-created file) directly onto the ProxySG. 

□ Create a local file on your local system; the ProxySG can browse to the file and install it. 

□ Enter a remote URL, where you placed an already-created file on an FTP or HTTP server to be 
downloaded to the ProxySG. 

□ Use the CLI inline command. 

To Create a CRL through the Management Console 
1. Select Configuration>SSL>CRLs. The CRL tab displays. 
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CRLS 

r CRLs 




Figure 7-8: Creating a new CRL 

2. Click New or highlight an existing CRL and click Edit. The Add/Edit CRL dialog box displays. 



Add CRL 




OK | Cancel | 

Figure 7-9: Adding a CRL 

3. Give the CRL a name. 

4. From the drop-down list, select the method to use to install the CRL; click Install. 

• Remote URL: 

Enter the fully-qualified URL, including the filename, where the CRL is located. To view the 
file before installing it, click View. Click Install. 

The Install CRL dialog displays. Examine the installation status that displays; click OK. 
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Figure 7-10: Specifying the Remote Location of a CRL 
• Local File: 

Click Browse to display the Local File Browse window. Browse for the CRL file on the local 
system. Open it and click Install. When the installation is complete, a results window opens. 
View the results, close the window, click Close. 



Upload and Install File 



Upload and Install the crl test 

1. Paste the file path into the box below or choose a file 
by clicking the Browse... button and opening the file. 

2. Click Install to upload and install the new file. It can 
take some time for the upload to complete. Your 
browser may be unresponsive during the upload. 

3. Oncetheinstallationiscompletedtheresults will b e 
displayed in a new page. Close the results page once 
you have finishe d viewing the re suits . 

File to upload: 

Browse... 

Install | Close | 

Figure 7-1 1 : Specifying the Local Location of a CRL 
• Text Editor: 

Copy a new CRL file into the window, and click Install. 

When the installation is complete, a results window opens. View the results, close the window, 

click Close. 
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Note: The Management Console text editor is a way to enter a CRL file. It is not a way to 

enter CLI commands. 



BlueQCoat Upload ard lnsta " File 




Figure 7-12: Using the Proxy SG Text Editor 
5. Click Apply. 

To Create a CRL through the CLI 

At the (config) command prompt, enter the following commands: 

SGOS# (conf ig) ssl 

SGOS# (config ssl) create crl list_name 
SGOS# (config ssl) edit crl list_name 
SGOS# (config ssl crl list_name) path url 

where url is a fully-qualified URL, including the filename, where the installable list is 
located. 

SGOS# (config ssl crl list_name) load list_name 
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To Create an Installable List through the CLI Inline Commands 

1. Copy the CRL to the clipboard. 

2. At the (config) command prompt, enter the following commands: 
SGOS# (conf ig) ssl 

SGOS# (config ssl) inline crl CRL_list_name eof 

Paste CRL here 

eof 



Troubleshooting Certificate Problems 

□ If the client does not trust the Certificate Signing Authority that has signed the ProxySG 
Appliance's certificate, an error message similar to the following appears in the event log: 

2004-02-13 07:29:28-05:O0EST " CFSSL : SSL_accept error : 14094416 : SSL 
routines : SSL3_READ_BYTES : sslv3 alert certificate unknown" 0 310000:1 
. . /cf_ssl . cpp: 1398 

This commonly occurs when you use the HTTPS-Console service on port 8082, which uses a 
self-signed certificate by default. When you access the Management Console over HTTPS, the 
browser displays a pop-up that says that the security certificate is not trusted and asks if you want 
to proceed. If you select No instead of proceeding, the browser sends an unknown CA alert to the 
ProxySG. 

You can eliminate the error message one of two ways: 

• If this was caused by the Blue Coat self-signed certificate (the certificate associated with the 
default keyring), import the certificate as from a trusted Certificate Signing Authority in 
Internet Explorer. 

• Import a certificate on the ProxySG that is signed by a well-known Certificate Signing 
Authority and use that for HTTPS Console access and HTTPS Reverse Proxy. 

□ If the ProxySG's certificate is not accepted because of a host name mismatch or it is an invalid 
certificate, you can correct the problem by creating a new certificate and editing the 
HTTPS-Console service to use it. For information on editing the HTTPS-Console service, see 
"Managing the HTTPS Console (Secure Console)" on page 152. 
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Section C: Managing the SSL Client 

The SSL client: 

□ Determines which certificates can be presented to origin servers if the secure server requires the 
ProxySG to present a certificate. 

□ Identifies the protocol the ProxySG uses in negotiations with origin servers. 

□ Identifies the cipher suites to be used with the certificate. 

You can change the protocol and the cipher suites used. 

You must associate a keyring with the SSL client if the ProxySG is obtaining content through HTTPS 
from an origin content server (OCS) that requires a client certificate to be presented. If the OCS 
requires a client certificate and no keyring is associated with the SSL client, the connections fails. For 
information on creating a keyring, see "Creating a Keyring" on page 271. 

Creating an SSL Client 

The ProxySG is configured with a default SSL client. 



Note: Only one SSL client can be created on a ProxySG. 



Creation of the SSL client means that for every HTTPS connection to the destination server, the 
ProxySG picks the parameters needed for negotiating the SSL connection from the SSL-client 
configuration. Thus, multiple SSL connections to different HTTPS destination servers can be 
supported with a single SSL-client configuration. This is similar to a browser where one configuration 
is used to negotiate multiple connections with different hosts. 

When the ProxySG is acting as an SSL client (SSL origination), SSL sessions are re-used until the server 
forces a fresh handshake or until the same session ID has been used 255 times. 

If you just need to change the protocol, the cipher suites, or the keyring associated with the SSL client, 
you do not need to recreate the client. Continue with "Associating a Keyring and Protocol with the 
SSL Client" on page 292 or "Changing the Cipher Suites of the SSL Client" on page 293. 

To Create the SSL Client through the CLI 

SGOS# (config ssl) create ssl-client default 

defaulting protocol to SSLv2v3TLSvl 
defaulting associated keyring-id to default 
ok 

To Delete the SSL Client through the CLI 

SGOS# (config ssl) delete ssl-client default 

ok 
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Associating a Keyring and Protocol with the SSL Client 

The SSL client, called default, already exists on the ProxySG. Keyrings that are not used to 
authenticate encrypted connections do not need to be associated with the SSL client. 



Important: Only one keyring can be associated with the SSL client at a time. 



To Associate a Keyring with the SSL Client and Change the Protocol Version through the Management 
Console 

1. Select Configuration>SSL>SSL Client. 

SSL Client 




Figure 7-13: SSL Client 

2. To use the SSL client, verify Use SSL Client is selected. 

3. Only keyrings with certificates can be associated with the SSL client, displayed in the Keyring 
drop-down list. Select the keyring used to negotiate with origin content servers through an 
encrypted connection. 

4. You can change the SSL Versions default from SSLv2v3TLSv1 to any other protocol listed in the 
drop-down list. 

5. Click Apply. 

To Associate a Keyring and Protocol with the SSL Client through the CLI 

1. To associate a keyring with the SSL client, enter the following commands at the (conf ig) 
command prompt: 

SGOS# (conf ig) ssl 

SGOS# (config ssl) edit ssl-client default 

SGOS# (conf ig ssl ssl-client default) keyring-id keyring_id 

SGOS# (config ssl ssl-client default) protocol {sslv2 | sslv3 | tlsvl | 

sslv2v3 | sslv2tlsvl | sslv3tlsvl | sslv2v3tlsvl } 



Note: To configure the ProxySG to accept only SSL version 3 traffic, for example, use the 

sslv3 parameter. To configure the ProxySG to accept SSL version 2 and version 3 
traffic, use the sslv2v3 parameter. 

2. View the results. The results also show the current value of the cipher suites, which is discussed in 
"Changing the Cipher Suites of the SSL Client" on page 293. 
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SGOS#(config ssl ssl-client default) view 



SSL-Client Name 


Keyring Name 


Protocol 


default 


default 


SSLv2v3TLSvl 



Changing the Cipher Suites of the SSL Client 

The cipher suite sets the encryption method used by the ProxySG. As the encryption key strength is 
determined by the signed certificate, configuring a higher cipher suite than defined by the certificate 
has no affect. Conversely, the cipher suite configuration must be high enough to accommodate 
certification encryption values. 

This can only be done through the CLI. 

To Change the Cipher Suite of the SSL Client through the CLI 

The default is to use all ciphers. 

You have a choice of using the interactive or non-interactive create command. 

Note: Director uses non-interactive commands in profiles and overlays to create cipher suites. 

For more information on Director, refer to the Blue Coat Director Configuration and 
Management Guide.) 



To change the cipher suites used through the: 

□ interactive command: continue with the next procedure. 

□ non-interactive command: skip to "To Change the Cipher Suites Non-interactively" on page 294. 

To Change the Cipher Suites using the Interactive Cipher-Suites Command: 

Note that the Use column in the set cipher- suite output below indicates that the default is to use 
all ciphers. 

1. Choose the cipher suites you want to use at the prompt. 

SGOS# (conf ig) ssl 

SGOS# (config ssl) edit ssl-client default 

SGOS# (conf ig ssl ssl-client default) cipher-suite 



SSL-Client Name 


Keyring Name 


Protocol 


default 




default 


SSLv2v3TLSvl 


Cipher# 


Use 


Description 


Strength 


1 


yes 


RC4-MD5 


Medium 


2 


no 


RC4-SHA 


Medium 


3 


no 


DES-CBC3-SHA 


High 


4 


no 


DES-CBC3 -MD5 


High 
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5 


no 


RC2 -CBC-MD5 


Medium 


6 


no 


RC4-64-MD5 


Low 


7 


no 


DES-CBC-SHA 


Low 


8 


no 


DES-CBC-MD5 


Low 


9 


no 


EXP1 024 -RC4 -MD5 


Export 


10 


no 


EXP1024-RC4-SHA 


Export 


11 


no 


EXP1024-RC2-CBC-MD5 


Export 


12 


no 


EXP1 024 -DES-CBC-SHA 


Export 


13 


no 


EXP-RC4 -MD5 


Export 


14 


no 


EXP-RC2-CBC-MD5 


Export 


15 


no 


EXP -DES-CBC-SHA 


Export 


16 


no 


AES128-SHA 


Medium 


17 


no 


AES256-SHA 


High 


Select cipher 


numbers to use, separated by commas: 


ok 








(Optional) View the results. Notice the change in the Use column. 


SGOS# (config 


ssl 


ssl-client default) view 




SSL-Client Name Keyring Name 


Protocol 


default 




default 


SSLv2v3TLSvl 


Cipher# 


Use 


Description 


Strength 


1 


yes 


RC4-MD5 


Medium 


2 


no 


RC4-SHA 


Medium 


3 


yes 


DES-CBC3-SHA 


High 


4 


yes 


DES-CBC3-MD5 


High 


5 


no 


RC2 -CBC-MD5 


Medium 


6 


no 


RC4-64-MD5 


Low 


7 


no 


DES-CBC-SHA 


Low 


8 


no 


DES-CBC-MD5 


Low 


9 


no 


EXP1 024 -RC4 -MD5 


Export 


10 


no 


EXP1024-RC4-SHA 


Export 


11 


no 


EXP1024-RC2-CBC-MD5 


Export 


12 


no 


EXP1 024 -DES-CBC-SHA 


Export 


13 


no 


EXP-RC4 -MD5 


Export 


14 


no 


EXP-RC2-CBC-MD5 


Export 


15 


no 


EXP -DES-CBC-SHA 


Export 


16 


no 


AES128-SHA 


Medium 


17 


no 


AES256-SHA 


High 



To Change the Cipher Suites Non-interactively 

Enter the following commands: 

SGOS# (conf ig) ssl 

SGOS#(config ssl) edit ssl-client default 

SGOS# (conf ig ssl ssl-client default) cipher-suite cipher- 
where [cipher- suite] can be any combination of the following: 



[te cipher-suite 
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1 . rc4 -md5 

2 . rc4 - sha 

3 . des-cbc3-sha 

4. des-cbc3-md5 

5. rc2-cbc-md5 

6 . rc4 - 64 -md5 

7 . des-cbc-sha 

8. des-cbc-md5 

9. expl024 -rc4 -md5 

10 . expl024-rc4-sha 

11 . expl024-rc2-cbc-md5 

12 . expl024 -des-cbc-sha 

13 . exp-rc4 -md5 

14 . exp-rc2-cbc-md5 

15 . exp-des-cbc-sha 

16 . aesl28 -sha 

17 . aes256-sha 



Notes: 

□ If you do not specify any attributes, the interactive mode is assumed, meaning that the cipher 
suites cannot be used by Director in profiles or overlays. 

□ Multiple cipher suites can be specified on the command line. 

Example 

SGOS# (config ssl ssl-client default) cipher-suite rc4-md5 des-cbc3-md5 
expl024-rc4 -md5 exp-des-cbc-sha 
ok 

SGOS# (config ssl ssl-client default) view 



SSL-Client Name 


Keyring Name 


Protocol 


default 




default 


SSLv2v3TLSvl 


Cipher# 


Use 


Description 


Strength 


1 


no 


RC4-MD5 


Medium 


2 


no 


RC4-SHA 


Medium 


3 


no 


DES-CBC3-SHA 


High 


4 


no 


DES-CBC3-MD5 


High 


5 


no 


RC2 -CBC-MD5 


Medium 


6 


no 


RC4-64-MD5 


Low 


7 


no 


DES-CBC-SHA 


Low 


8 


no 


DES-CBC-MD5 


Low 


9 


no 


EXP1 024 -RC4 -MD5 


Export 


10 


no 


EXP1 024 -RC4 - SHA 


Export 


11 


no 


EXP1024-RC2-CBC-MD5 


Export 


12 


no 


EXP1 024 -DES-CBC-SHA 


Export 


13 


no 


EXP-RC4 -MD5 


Export 


14 


no 


EXP-RC2-CBC-MD5 


Export 


15 


yes 


EXP-DES-CBC-SHA 


Export 


16 


no 


AES 12 8 -SHA 


Medium 


17 


no 


AES256-SHA 


High 
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Troubleshooting Server Certificate Verification 

Server certificate verification can be disabled for all upstream hosts or specific upstream hosts. The 
ProxySG, by default, verifies the SSL certificate presented by the upstream HTTPS server. However, it 
fails to negotiate the SSL connection if SSL certificate verification fails. 

The two most common causes of server certificate verification failure are: 

□ The absence of a suitable CA certificate on the ProxySG. Ensure that the ProxySG is configured 
with the relevant CA certificates to avoid unwanted verification failures. The default behavior can 
be changed by using the http ssl -verify- server option. 

If a forwarding host of type HTTPS server is being used, you can override the default behavior by 
changing the ssl-verify-server option on a per-host basis . 

□ The server is using a self-signed certificate. In this case, you need to change the keyring to one that 
has a CA certificate. 



Setting the SSL Negotiation Timeout 

The SSL negotiation timeout value dictates the time a ProxySG waits for a new SSL handshake to 
complete. This value applies to both HTTPS Reverse Proxy and SSL origination. 



You can change the default SSL negotiation timeout value if the default, 300 seconds, is not sufficient 
for your environment. This value can only be changed through the CLI; it cannot be set from the 
Management Console. 



To change the HTTPS Reverse Proxy timeout period, enter the follow commands from the command 
prompt: 



SGOS# (conf ig) ssl 
SGOS#(config ssl) 
300 

SGOS#(config ssl) 



view ssl -nego- timeout 
ssl -nego- timeout seconds 



296 



Chapter 7: Using Secure Services 



Section D: Configuring HTTP or HTTPS Origination to the Origin Content Server 

Section D: Configuring HTTP or HTTPS Origination to the Origin Content 
Server 

In previous procedures, you configured HTTPS Reverse Proxy to the ProxySG. In two common 
termination scenarios, you must also configure HTTPS origination to the Origin Content Server 
(OCS). 

The first two scenarios are used to provide a secure connection between the proxy and server, if, for 
example, the proxy is in a branch office and is not co-located with the server. 

Table 7.2: Scenario 1 : HTTPS Reverse Proxy with HTTPS Origination 



HTTPS Rpvpr.qp Provy ^ 


HTTPS Origination ^ 


Client — HTTPS ProxySG 


ProxySG- HTTPS- Origin Content Server 


Steps 


Steps 


• Configure a keyring. 


• (Optional) Add a forwarding host. 


• Configure the SSL client. 


• (Optional) Set an HTTPS port. 


• Configure the HTTPS service. 


• (Optional) Enable server certificate verification. 



Table 7.3: Scenario 2: HTTP Termination with HTTPS Origination 







Client — HTTP ProxySG 

Steps: 

• Client is explicitly proxied. 


ProxySG- HTTPS— Origin Content Server 

Steps 

• Server URL rewrite. 

-or- 

• Add a forwarding host (only for SGOS 3.1 or higher). 

• Set an HTTPS port. 

• (Optional) Enable server certificate verification. 



Using server URL rewrite is the preferred method. For information on rewriting the server URL, refer 
to the Blue Coat ProxySG Content Policy Language Guide. 

You can only configure HTTPS origination through the CLI. You cannot use the Management Console. 
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To Configure HTTPS Origination: 

At the (config) command prompt, enter the following commands: 

SGOS# (config forwarding) create host_alias hostname https [ =port_number ] 

server ssl-verify-server=yes 



where: 



host_alias 


ip_address 


Specifies the IP address of the OCS. 


host name 


url 


Specifies the URL of the OCS, such as www.bluecoat.com. 


https 


[ =port number ] 


Specifies the port number on the OCS in which HTTPS is 
listening. 


server 




Specifies to use the relative path for URLs in the HTTP 
header because the next hop is a Web server, not a proxy 
server. Proxy is the default. 


ssl-verify- 

server= 


yes | no 


Specifies whether the upstream server certificate should 
be verified. You can only enable this command if the 
upstream host is a server, not a proxy. 



The next scenario is useful when the ProxySG is deployed as a reverse proxy This scenario is used 
when it's not necessary for a secure connection between the proxy and server. For information on 
using the ProxySG as a reverse proxy, see "Choosing the HTTP Proxy Profile" on page 200. 

Table 7.4: Scenario 3: HTTPS Reverse Proxy with HTTP Origination 



HTTPS Rpuprcp Prnvy ^ 


HTTP Oriqinatinn ^ 


Client — HTTPS ProxySG 


ProxySG— HTTP Origin Content Server 


Steps 


Steps 


• Configure a keyring 


• Server URL rewrite 


• Configure the SSL client 


-or- 


• Configure the HTTPS service 


• Add a forwarding host (only for SGOS 3.1 or higher) 




• Set an HTTP port 



Using server URL rewrite is the preferred method. For information on rewriting the server URL, refer 
to the Blue Coat ProxySG Content Policy Language Guide. 

You can only configure HTTP origination through the CLI. You cannot use the Management Console. 

To Configure HTTP Origination: 

At the (config) command prompt, enter the following commands: 

SGOS# (config forwarding) create host_alias host_name http [=port_number] 

server 
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where: 



host_alias 


ip_address 


Specifies the IP address of the OCS. 


host_name 


url 


Specifies the URL of the OCS, such as www.bluecoat.com. 


http 


[=por t number] 


Specifies the port number on the OCS in which HTTP is 
listening. 


server 




server specifies to use the relative path for URLs in the 
HTTP header because the next hop is a Web server, not a 
proxy server. Proxy is the default. 



Creating Policy for HTTP and HTTPS Origination 

Forwarding hosts must be already created on the ProxySG before forwarding policy can be created. 

To Create a Policy using CPL 

<f orward> 

url . host=-host_name forward ( host_alias ) 

To Create a Policy using VPM 

1. In the VPM module, create a Forwarding layer. 

2. Set the Destination to be the URL of the OCS. 

3. Set the Action to forward to the forwarding host and configure parameters to control forwarding 
behavior. 
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Section E: Advanced Configuration 

This section includes the following topics: 

□ "Importing an Existing Keypair and Certificate” 

□ "About Certificate Chains" 

□ "Importing a CA Certificate” 

□ "Creating CA Certificate Lists” 



Importing an Existing Keypair and Certificate 

If you have a keypair and certificate from another system, you can import it for use on a different 
system. You can also import a certificate chain containing multiple certificates in a single operation. 
Use the inline certificate command to import multiple certificates through the CLI. 

If you are importing a keyring and one or more certificates onto a ProxySG, first import the keyring, 
followed by the related certificates. The certificates contain the public key from the keyring, and the 
keyring and certificates are related. 



To Import a Keyring through the Management Console 

1. Copy the already-created keypair onto the clipboard. 

2. Select Configuration>SSL>Keyrings>SSL Keyrings. 

3. Click Create. 

The Create Keyring dialog appears. 



^ Create Keyring 



P 

(• Do not show keypair Show keypair to director 
1 1 024 - bit keyring 



31 



d 

P” Keyring Password: |" 



OK | Cancel | 

Figure 7-14: Import a Keyring 



Keyring Settings: 
Keyring Name: 

C Show keypair 
(• Create a new 
<~ Import keyring 
Keyring: 
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4. Fill in the dialog window as follows: 

• Keyring Name: Give the keyring a meaningful name to you. 

• Select the show option: 

• show: Keyrings created with this attribute can be included as part of a profile or overlay 
pushed by Director. 

• show-director: Keyrings created with this attribute can be included as part of a profile 
or overlay pushed by Director. 

• no-show: Keyrings created with this attribute cannot be part of a profile. The no-show 
option is provided as additional security for environments where the keys will never be 
used outside of the particular ProxySG. 

• Select the keyring length in the Create a new -bit keyring field. A length of 1024 bits is the 

maximum (and default). Longer keypairs provide better security, but with a slight 
performance expense on the ProxySG. Be aware that the maximum key length allowed for 
international export might be different than the default. For deployments reaching outside of 
the US, determine the maximum key length allowed for export. 

Click OK. The keyring, containing a keypair, is created with the name you chose. It does not 
yet have an associated certificate associated. To associate a certificate, see "Deleting an 
Existing Keyring and Certificate" on page 275. 

-or- 

• Select the Import keyring radio button. 

The grayed-out Keyring field becomes enabled, allowing you to paste in the already existing 
keypair. The certificate associated with this keypair must be imported separately. 

If the keypair that is being imported has been encrypted with a password, select Keyring 
Password and enter the password into the field. 

5. Click OK. 

To Import a Certificate and Associate it with a Keyring through the Management Console 

1. Copy the certificate onto the clipboard. 

2. Select Configuration>SSL>Keyrings and click Edit/view. 

3. From the drop-down list, select the keyring that you just imported. 

4. Click Import in the Certificate field. 

5. Paste the certificate into the Import Certificate dialog that appears. Be sure to include the 

BEGIN CERTIFICATE and END CERTIFICATE statements. 

6. Click OK. 

To Import a Keyring through the CLI Using Inline Commands 

1. Copy the keyring to the clipboard. 

2. At the (config) command prompt, enter the following commands: 
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SGOS# (conf ig) ssl 

SGOS# (config ssl) inline {keyring show | show-director | no-show} keyring_id 
eof 

Paste keypair here 
eof 



where: 

• show allows the keys, and everything in the keys, to be exported. 

• no-show prevents the keypair from being exported. 

• show-director is a keyring viewable only if Director is issuing the command using a 
SSH-RSA connection. 



Note: The choice of show/show-director / no-show has implications for whether keyrings 

are included in profiles and backups created by Director. For more information, refer 
to the Blue Coat Director User Guide. 



• eof: End-of-file marker. This can be anything, as long as it does not also appear in the 
inline text. (If it appears in the inline text, the inline command completes at that point.) 

To Import a Certificate and Associate it with a Keyring through the CLI 



Note: The keyring you want to associate with the certificate must already be on this ProxySG. 

The key and certificate must be imported onto the ProxySG in PEM (base64 encoded text) 
format. 



1. Copy the certificate or certificate chain to the clipboard. Be sure to include the begin 

CERTIFICATE and END CERTIFICATE statements. 

2. At the (config) command prompt, enter the following commands: 

SGOS# (conf ig) ssl 

SGOS# (config ssl) inline certificate keyring_id eof 

Paste certificate here 

eof 



About Certificate Chains 

A certificate chain is one that requires that the certificates form a chain where the next certificate in the 
chain validates the previous certificate, going up the chain to the root, which is signed by a 
well-known root certificate provider. However, expiration is done at the single certificate level and is 
checked independently of the chain verification. Each certificate in the chain must not have expired 
for the entire chain to be valid. You can import a certificate chain containing multiple certificates in a 
single operation. 

The valid certificate chain can be presented to a browser. To get the ProxySG to present a valid 
certificate chain, the keyring for the HTTPS service must be updated. 
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The ProxySG Appliance's CA-certificate list must also be updated if the ProxySG uses HTTPS to 
communicate with the origin server and if the ProxySG is configured, through the 
ssl -verify- server option, to verify the certificate (chain) presented by HTTPS server. If the 
ProxySG uses HTTP to communicate with the origin server, updating the CA-certificate list has no 
effect. 

Importing a CA Certificate 

A CA Certificate is a certificate that verifies the identity of a Certificate Authority. The certificate is 
used by the ProxySG to verify server certificates and client certificates. 

To Import an Approved CA Certificate through the Management Console 

1. Copy the certificate to the clipboard. 

2. Select Configuration>SSL>CA Certificates>CA Certificates. 

The CA Certificates tab displays, with its list of existing CA certificates. 



CA Certificates 

CA Certificates: - 



CA Certificate Lists 



Name 



CertPlus Class3P 



KeyMail.PTT 



Thawte Freemail 



CWHKT.SecureNetA 



FESTE 



NetLockJJzleti 



Certisign_AC3S 



Thawte_Pers_Prem 



DST UPS RootCA 



DST_Retail 



CertPlus Class2P 



Import 



View 



Delete 



Figure 7-15: CA Certificates 

3. Click Import. 



The Import CA Certificate dialog displays. 
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Figure 7-16: Import CA Certificate Dialog 

4. Give the certificate a name. 

Note: Spaces in CA Certificate names are not supported. Including a space can cause 

unexpected errors while using such certificates. 

5. Paste the signed CA Certificate into the Import CA Certificate field. 

6. Click OK. 

7. When the certificate displays in the Certificate tab, click Apply. 

To View a CA Certificate through the Management Console 

1. Select Configuration>SSL>CA Certificates>CA Certificates. 

2. Select the certificate you want to view. 

3. Click View. 

The certificate displays. 



- View CA Certificate 



Import CA Certificate: 



CA Cert Name: |" 
CA Certificate: 



BEGIN CERTIFICATE-- 

MIIEJzCCA5CgAwlBAglEN35hxiANBgkqhkiG9wOBAQQFADCBgzELMAkGA1UEBhMC 
WM xLTArBgNVBAoTJ EZpcnN 01 E R hdG E gR G InaXR hbCB DZXJ0aWZpY2FCGXMgSW 
5i 

LiFFMEMGA1UEAxM8Rmlyc3QgRGF0YSBEaWdpdGFslENIcnRpZmlirXRIcyBJbmMu 
I E N IcnR pZmlfrXR pb24gQXV0aG 9yaXR 5M B 4XD T k5M D cwM zE 4N D czN FoXD TE5M D c 



OK | Close | 

Figure 7-17: View CA Certificate 
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4. Examine the contents and click Close. 

To Delete a CA Certificate through the Management Console 

1. Select Configuration>SSL>CA Certificates>CA Certificates. 

2. Select the certificate to delete. 

3. Click Delete. 

4. Click OK. 

5. Click Apply. 

To Import a CA Certificate through the CLI Using Inline Commands 

1. Copy the certificate to the clipboard. 

2. At the (config) command prompt, enter the following commands: 

SGOS# (conf ig) ssl 

SGOS# (config ssl) inline ca-certif icate ca_certificate_name eof 

Paste certificate here 

eof 

3. (Optional) You can view the certificate you just imported, a summary of the just-imported 
certificate, or a summary of all CA Certificates. 

a. To view the certificate you just imported: 

SGOS# (config ssl) view ca-certif icate ca_certificate_name 
BEGIN CERTIFICATE 

MIIEJzCCA5CgAwIBAgIEN35hxjANBgkqhkiG9wOBAQQFADCBgzELMAkGAlUEBhMC 
WMxLTArBgNVBAoTJEZpcnNO IERhdGEgRGlnaXRhbCBDZXJ0aWZpY2F0ZXMgSW5 j 
L j FFMEMGAlUEAxM8Rmlyc3QgRGF0YSBEaWdpdGFsIENlcnRpZml j YXRlcyBJbmMu 
IENlcnRpZml j YXRpb24gQXV0aG9yaXR5MB4XDTk5MDcwMzE4NDczNFoXDTE5MDcw 
MzE5MTczNFowgYMxCzAJBgNVBAYTAlVTMS0wKwYDVQQKEyRGaXJzdCBEYXRhIERp 
Z210YWwgQ2VydGlmaWNhdGVzIEluYy4xRTBDBgNVBAMTPEZpcnN0IERhdGEgRGln 
aXRhbCBDZXJ0aWZpY2F0ZXMgSW5 j LiBDZXJ0aWZpY2F0aW9uIEFldGhvcml0eTCB 
nTANBgkqhkiG9wOBAQEFAAOBiwAwgYcCgYEA3xwUHgm5v6RAciCZebaEIvTXhZLF 
BCToBy4C5BeVBTeVdj 3 8seUPhw5iuSwwlybhCxVnAKYV3uiNy5XsAlhSwEdlM0xW 
nwof BMA3UI FXut / 6 8mtn68vQgA/ ZV5UQZXsGRV j rrrRe4 5MVK5m8 1 ikv+ OKf Rysu 
TOsOKDKZDu/ /b6ECAQOjggGmMIIBoj ARBglghkgBhvhCAQEEBAMCAAcwgawGAlUd 
HwSBpDCBoTCBnqCBm6CBmKSBlTCBkj ELMAkGAlUEBhMCWMxLTArBgNVBAoTJEZp 
cnN0IERhdGEgRGlnaXRhbCBDZXJ0aWZpY2F0ZXMgSW5 j L j FFMEMGAlUEAxM8Rmly 
c3QgRGF0YSBEaWdpdGFsIENlcnRpZml j YXRlcyBJbmMuIENlcnRpZml j YXRpb24g 
QXV0aG9yaXR5MQ0wCwYDVQQDEwRDUkwxMCsGAlUdEAQkMCKADzE5OTkwNzAzMTg0 
NzMOWoEPMj AxOTA3MDMxODQ3MzRaMAsGAlUdDwQEAwIBBj AfBgNVHSMEGDAWgBSm 
uCDJFkuPTlwMw8PumA0 + fu5WVTAdBgNVHQ4EFgQUprggyRZLj 0 9cDMPD7pgNPn7u 
VlUwDAYDVROTBAUwAwEB/ zA7BgNVHSUENDAyBggrBgEFBQcDAQYIKwYBBQUHAwIG 
CCsGAQUFBwMDBggrBgEFBQcDBAYIKwYBBQUHAwgwGQYJKoZIhvZ9B0EABAwwChsE 
Vj QuMAMCBJAwDQYJKoZIhvcNAQEEBQADgYEAEObEaCOpbLeXSbFzNp3+v3KiDhLC 
KlEGH2mTlDARNYVOqHkG4 3 FVPBxWYx5Ee2qBw j BlbN7z8gzDTsp/ycbAXl/vxAZi 
qk/ 6EN4yzOAu/2rixcdFKXU5+YxZC8ZrmQSYWsy6v7F4ApGqtoeA01cUWzz8zAPK 
hqGZqDpta2V+Ubg= 

END CERTIFICATE 
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b. To view a summary of the certificate you just imported. 

SGOS# (config ssl) view summary ca-certificate ca_certificate_name 

CA Certificate ID: ca_certificate_name 

Is certificate valid? yes 

CA: First Data Digital Certificates Inc. 

Expiration Date: Jul 03 19:17:34 2019 GMT 

Fingerprint: 70 : B5 : 7C : 48 : 81 : 95 : 3E : 80 : DC : 28 : 9B : BA : EF : IE : E4 : 85 

c. To view summaries of all CA Certificates on the ProxySG: 

SGOS# (config ssl) view summary ca-certificate 

A long list of certificates are displayed, each with the summary information displayed 
above. 

Creating CA Certificate Lists 

A CA certificate list can refer to any subset of the available CA Certificates on the ProxySG. When 
configuring an HTTPS service to do HTTPS Reverse Proxy, this list can be specified to restrict the set 
of certificate authorities that are trusted to validate client certificates presented to that service. 

The default is that no list is configured; all certificates are used in authentication. 

To Create a CA-Certificate List through the Management Console 
1. Select Configuration>SSL>CA Certificates>CA Certificate Lists. 

CA Certificates CA Certificate Lists | 

r CA Certificate Lists: 




Figure 7-18: SSL CA-Certificates Lists Dialog 
The current CA-Certificate lists display in the pane. 
2. Click New to create a new list. 

The Create CA Certificate List dialog displays. 
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Figure 7-19: Create CA Certificate List Dialog 

3. Enter a name meaningful to you for the list in the CA-Certificate List Name field. 

4. To add CA Certificates to the list, highlight the certificate and click Add. You cannot add a 
certificate to a certificate list if it is not already present. 

5. To remove CA Certificates from the list, highlight the certificate in the Add list and click Remove. 

6. Click OK; click Apply. 

To Create CA-Certificate Lists through the CLI 

1. At the (config) command prompt, view the CA certificates already existing on the system. You 
cannot add a certificate to a certificate list if it is not already present. 

SGOS# (config) ssl 

SGOS# (config ssl) view summary ca-certificate 
All the CA Certificates on the system display. 

2. Enter the followings commands to create a list and add existing certificates to the list you just 
generated. 

SGOS# (config ssl) create ccl list_name 
SGOS# (config ssl) edit ccl list_name 

The prompt changes, putting you in ccl submode. 

SGOS# (config ssl ccl list_name ) add ca_cert_name 

3. Repeat the above command until you have entered all the needed certificates. You can have more 
than one CA-Certificate list. Each list can have an unlimited number of certificates. 

4. (Optional) View the list. 

SGOS# (config ssl ccl list_name) view 
CA Certificate ID: VRSN_Secure_Server_CA 
Is certificate valid? yes 
CA: RSA Data Security, Inc. 

Expiration Date: Jan 07 23:59:59 2010 GMT 

Fingerprint : 74 : 7B : 82 : 03 : 4 3 : F0 : 00 : 9E : 6B : B3 : EC : 4 7 : BF : 8 5 : A5 : 93 
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CA Certificate ID: DeutscheTelekom 
Is certificate valid? yes 
CA: Deutsche Telekom AG 

Expiration Date: Jul 09 23:59:00 2019 GMT 

Fingerprint : 9B : 34 : 0D : 1A: 31 : 5B : 97 : 46 : 26 : 98 : BC : A6 : 13 : 6A : 71 : 96 

CA Certificate ID: CWHKT_SecureNetA 
Is certificate valid? yes 
CA: C&W HKT SecureNet CA Class A 
Expiration Date: Oct 15 23:59:00 2009 

Fingerprint : E2 : D5 : 2 0 : 23 : EC : EE : B8 : 72 : El : 2B : 5D : 2 9 : 6F : FA : 43 : DA 

To Delete a CA Certificate through the CLI 

At the (config) command prompt, enter the following commands: 

SGOS# (conf ig) ssl 

SGOS# (config ssl) delete ca-certif icate ca_certificate_name 
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Enterprise- wide security begins with security on the ProxySG itself, and continues with controlling 
user access to the Intranet and Internet. 

Table 8.1 defines some common security and authentication terms. 

Table 8.1 : Security and Authentication Terms 



Term 


Definition 


proxy 


Caches content, filters traffic, monitors Internet and intranet resource usage, 
blocks specific Internet and intranet resources for individuals or groups, and 
enhances the quality of Internet or intranet user experiences. 

A proxy can also serve as an intermediary between a Web client and a Web server 
and can require authentication to allow identity based policy and logging for the 
client. 

The rules used to authenticate a client are based on the policies you create on the 
ProxySG, which can reference an existing security infrastructure — LDAP, 
RADIUS, IWA, and the like, discussed in more detail in Chapter 9: "Using 
Authentication Services" on page 339. 


explicit proxy 


A configuration in which the browser is explicitly configured to communicate 
with the proxy server for access to content. 

This is the default for the ProxySG, and requires configuration for both browser 
and the interface card. 


transparent proxy 


A configuration in which traffic is redirected to the ProxySG without the 
knowledge of the client browser. No configuration is required on the browser, but 
network configuration, such as an L4 switch or a WCCP-compliant router, is 
required. 


forward proxy 


A proxy server deployed close to the clients and used to access many servers. A 
forward proxy can be explicit or transparent. 


reverse proxy 


A proxy that acts as a front-end to a small number of pre-defined servers, 
typically to improve performance. Many clients can use it to access the small 
number of predefined servers. 


SSL 


A standard protocol for secure communication over the network. Blue Coat 
recommends using this protocol to protect sensitive information. 


authentication 


The process of identifying a specific user. 


authorization 


The permissions given to a specific user. 
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Term 


Definition 


realms 


A realm is a named collection of information about users and groups. The name is 
referenced in policy to control authentication and authorization of users for access 
to Blue Coat Systems ProxySG services. Multiple authentication realms can be 
used on a single ProxySG. Realm services include IWA, LDAP, Local, and 
RADIUS. For detailed information on realms, see Chapter 9: "Using 
Authentication Services" on page 339. 


serial console 


A device that allows you to connect to the ProxySG when it is otherwise 
unreachable, without using the network. It can be used to administer the ProxySG 
through the CLI. You must use the CLI to use a serial console. 

Anyone with access to the serial console can change the administrative access 
controls, so physical security of the serial console is critical. 



SSH and HTTPS are the recommended (and default) methods for managing access to the ProxySG. 
SSL is the recommended protocol for communication between the ProxySG and a realm's off-box 
authentication server. 

This chapter contains the following sections: 

□ "Controlling Access to the ProxySG" 

□ "Controlling Access to the Internet and Intranet” 
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Section A: Controlling Access to the ProxySG 

You can control access to the ProxySG several ways: by limiting physical access to the system, by 
using passwords, restricting the use of console account, through per-user RSA public key 
authentication, and through Blue Coat Content Policy Language (CPL). How secure the system needs 
to be depends upon the environment. 

This section contains: 

□ "Limiting Access to the ProxySG Appliance" 

□ "About Password Security” 

□ "Limiting User Access to the ProxySG — Overview” 

□ "Moderate Security: Restricting Management Console Access Through the Console Access 
Control List (ACL)" 

□ "Maximum Security: Administrative Authentication and Authorization Policy" 

Limiting Access to the ProxySG Appliance 

You can limit access to the ProxySG appliance by: 

□ Restricting physical access to the system and by requiring a PIN to access the front panel. 

□ Restricting the IP addresses that are permitted to connect to the ProxySG CLI. 

□ Requiring a password to secure the Setup Console. 

These methods are in addition to the restrictions placed on the console account (a console account user 
password) and the Enable password. For information on using the console account, see "Changing the 
Username and Password through the Management Console" on page 63. 

By using every possible method (physically limiting access, limiting workstation IP addresses, and 
using passwords), the ProxySG is very secure. 

This section discusses: 

□ "Requiring a PIN for the Front Panel" 

□ "Limiting Workstation Access" 

□ "Securing the Serial Port" 

Requiring a PIN for the Front Panel 

On systems that have a front panel display, you can create a four-digit PIN to protect the system from 
unauthorized use. The PIN is hashed and stored. You can only create a PIN from the command line. 

To create a front panel PIN, after initial configuration is complete: 

From the (config) prompt: 

SGOS# (config) security front-panel-pin PIN 

where PIN is a four-digit number. 
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To clear the front-panel PIN, enter 

SGOS# (config) security front-panel-pin 0000 

Limiting Workstation Access 

During initial configuration, you have the option of preventing workstations with unauthorized IP 
addresses from accessing the CLI. If this option is not enabled, all workstations are allowed to access 
the CLI. You can also add allowed workstations later to the access control list (ACL). (For more 
information on limiting workstation access, see "Moderate Security: Restricting Management Console 
Access Through the Console Access Control List (ACL)” on page 315.) 

Securing the Serial Port 

If you choose to secure the serial sort, you must provide a Setup Console password that is required to 
access the Setup Console in the future. 

Once the secure serial port is enabled: 

□ The Setup Console password is required to access the Setup Console. 

□ Am authentication challenge (username and password) is issued to access the CLI through the 
serial port. 

To recover from a lost Setup Console password, you can: 

□ Use the Front Panel display to either disable the secure serial port or enter a new Setup Console 
password. 

□ Use the CLI restore-defaults factory-defaults command to delete all system settings. For 
information on using the restore-defaults factory-defaults command, see 
"Factory-Defaults” on page 941. 

□ Use the reset button (if the appliance has a reset button) to delete all system settings. 

To enable the secure serial port, refer to the Installation Guide for your platform. 

About Password Security 

In the ProxySG, the console administrator password, the Setup Console password, and Enable 
(privileged-mode) password are hashed and stored. It is not possible to reverse the hash to recover the 
plaintext passwords. 

In addition, the show config and show security CLI commands display these passwords in their 
hashed form. The length of the hashed password depends on the hash algorithm used so it is not a 
fixed length across the board. 

Passwords that the ProxySG uses to authenticate itself to outside services are encrypted using 
triple-DES on the appliance, and using RSA public key encryption for output with the show config 
CLI command. You can use a third-party encryption application to create encrypted passwords and 
copy them into the ProxySG using an encrypted-password command (which is available in several 
modes and described in those modes). If you use a third-party encryption application, verify it 
supports RSA encryption, OAEP padding, and Base64 encoded with no new lines. 
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These passwords, set up during configuration of the external service, include: 

□ Access log FTP client passwords (primary, alternate) — For configuration information, see "Editing 
the FTP Client" on page 918 

□ Archive configuration FTP password — For configuration information, see "Archive 
Configuration" on page 80 

□ RADIUS primary and alternate secret — For configuration information, see "Defining RADIUS 
Realm Properties" on page 392 

□ LDAP search password — For configuration information, see "LDAP Search & Groups Tab 
(Authorization and Group Information)" on page 369 

□ Content filter download passwords — For configuration information, see Chapter 18: "Content 
Filtering" on page 785 

Limiting User Access to the ProxySG — Overview 

When deciding how to give other users read-only or read-write access to the ProxySG, sharing the 

basic console account settings is only one option. The following summarizes all available options: 



Note: If Telnet Console access is configured, Telnet can be used to manage the ProxySG with 

behavior similar to SSFI with password authentication. 

SSL configuration is not allowed through Telnet, but is permissible through SSFI. 

Behavior in the following sections that applies to SSFI with password authentication also 
applies to Telnet. Use of Telnet is not recommended because it is not a secure protocol. 



□ Console account — minimum security 

The console account username and password are evaluated when the ProxySG is accessed from 
the Management Console through a browser and from the CLI through SSFI with password 
authentication. The Enable (privileged-mode) password is evaluated when the console account is 
used through SSFI with password authentication and when the CLI is accessed through the serial 
console and through SSFI with RSA authentication. The simplest way to give access to others is 
sharing this basic console account information, but it is the least secure and is not recommended. 

To give read-only access to the CLI, do not give out the Enable (privileged-mode) password. 

□ Console access control list — moderate security 

Using the access control list (ACL) allows you to further restrict use of the console account and 
SSFI with RSA authentication to workstations identified by their IP address and subnet mask. 
When the ACL is enforced, the console account can only be used by workstations defined in the 
console ACL. Also, SSFI with RSA authentication connections are only valid from workstations 
specified in the console ACL (provided it is enabled). 
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After setting the console account username, password, and Enable (privileged-mode) password, 
use the CLI or the Management Console to create a console ACL. See "Moderate Security: 
Restricting Management Console Access Through the Console Access Control List (ACL)" on 
page 315. 

□ Per-user RSA public key authentication — moderate security 

Each administrator's public keys are stored on the appliance. When connecting through SSH, the 
administrator logs in with no password exchange. Authentication occurs by verifying knowledge 
of the corresponding private key. This is secure because the passwords never go over the network. 

This is a less flexible option than CPL because you cannot control level of access with policy, but it 
is a better choice than sharing the console credentials. 

□ Blue Coat Content Policy Language (CPL) — maximum security 

CPL allows you to control administrative access to the ProxySG through policy. If the credentials 
supplied are not the console account username and password, policy is evaluated when the 
ProxySG is accessed through SSH with password authentication or the Management Console. 
Policy is never evaluated on direct serial console connections or SSH connections using RSA 
authentication. 

• Using the CLI or the Management Console GUI, create an authentication realm to be used for 
authorizing administrative access. For administrative access, the realm must support BASIC 
credentials — for example, LDAP, RADIUS, Local, or IWA with BASIC credentials enabled. For 
more information on realms, see Chapter 9: "Using Authentication Services" on page 339. 

• Using the Visual Policy Manager, or by adding CPL rules to the Local or Central policy file, 
specify policy rules that: (1) require administrators to log in using credentials from the 
previously-created administrative realm, and (2) specify the conditions under which 
administrators are either denied all access, given read-only access, or given read-write access. 
Authorization can be based on IP address, group membership, time of day, and many other 
conditions. For more information, see "Defining Policies Using the Visual Policy Manager" on 
page 318. 

• To prevent anyone from using the console credentials to manage the ProxySG, set the console 
ACL to deny all access (unless you plan to use SSH with RSA authentication). For more 
information, see "Moderate Security: Restricting Management Console Access Through the 
Console Access Control List (ACL)” on page 315. You can also restrict access to a single IP 
address that can be used as the emergency recovery workstation. 



The following chart details the various ways administrators can access the ProxySG console and the 
authentication and authorization methods that apply to each. 

Table 8.2: ProxySG Console Access Methods/Available Security Measures 



Security Measures Available 


Serial Console 


SSH with 
Password 
Authentication 


SSH with RSA 
Authentication 


Management 

Console 


Username and password evaluated 
(console-level credentials) 




V 




V 
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Table 8.2: ProxySG Console Access Methods/Available Security Measures (Continued) 



Console Access List evaluated 




(if console 
credentials are 
offered) 




^(if console 
credentials are 
offered) 


CPL <Admin> Layer evaluated 




v ^(see Note 1 
below) 




"^(see Note 2 
below) 


Enable password required to enter 
privileged mode (see Note 2 below) 




w 






CLI line-vty timeout command 
applies. 










Management Console Login/Logout 








✓ 



Note 1: When using SSH (with a password) and credentials other than the console account, the enable 
password is actually the same as the login password. The privileged mode password set during 
configuration is used only in the serial console, SSH with RSA authentication, or when logging in with 
the console account. 

Note 2: In this case, user credentials are evaluated against the policy before executing each CLI 
command. If you log in using the console account, user credentials are not evaluated against the 
policy. 

Moderate Security: Restricting Management Console Access Through 
the Console Access Control List (ACL) 

The ProxySG allows you to limit access to the Management Console and CLI through the console 
ACL. An ACL, once set up, is enforced only when console credentials are used to access either the CLI 
or the Management Console, or when an SSH with RSA authentication connection is attempted. The 
following procedure specifies an ACL that lists the IP addresses permitted access. 

To Create an ACL through the Management Console 

1. Select Configuration>Authentication>Console Access>Console Access. 



315 



Blue Coat ProxySG Configuration and Management Guide 



Section A: Controlling Access to the ProxySG 



Console Account Console Access 

r ACL for built-in administration 




[~| Enforce ACL for built-in administration 



Figure 8-1 : Console Access Tab 
2. (Optional) To add a new address to the ACL, click New. 
The Add List Item dialog is displayed. 




Figure 8-2: Add List Item Dialog 

a. In the IP/Subnet fields, enter a static IP address. 

b. In the Mask fields, enter the subnet mask. To restrict access to an individual workstation, 
enter 255 . 255 . 255 . 255 . 

c. Click OK to add the workstation to the ACL and return to the Console Access page. 

d. Repeat step 2 to add other IP addresses. 

3. (Optional) To remove a source address from the ACL, select the address to remove from the 
Console Access page and click Delete. 

4. (Optional) To change a source IP address, select the IP address to revise and click Edit. See step 2, 
above, for details. 

5. To impose the ACL defined in the list box, select Enforce ACL for built-in administration. To allow 
access to the CLI or Management Console using console account credentials from any 
workstation, deselect the checkbox. The ACL is ignored. 
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Important: Before you enforce the ACL, verify the IP address for the workstation you are using 

is included in the list. If you forget, or you find that you mistyped the IP address, 
you must correct the problem using the serial console. 



6. Click Apply. 

To Create an ACL through the CLI 

1. At the (config) command prompt, enter the following command to add workstation IP 
addresses to the ACL: 

SGOS# (config) security allowed-access add ip_address [ subnet_mask ] 



Note: If you omit the subnet mask, the default subnet mask of 255 . 255 . 255. 255 is 

assumed. 



2. Repeat step 1 for each workstation that you need to add to the console access list. 

3. At the (config) command prompt, enter the following command to enforce the ACL created in 
step 1 

SGOS# (config) security enforce-acl enable 

Only those workstation IP addresses added to the ACL are able to use the Management 
console account to administer the ProxySG. Verify that the IP address for the workstation you 
are using is included in the list. 

4. To disable the ACL and open through the access to the console account user, enter the following 
command: 

security enforce-acl disable 

5. To remove an IP address and subnet mask from the ACL, enter the following command: 

SGOS# (config) security allowed-access remove ip_address [subnet_mask] 



Note: If you omit the subnet mask, the default subnet mask of 255 . 255 . 255. 255 is 

assumed. 



Maximum Security: Administrative Authentication and Authorization 
Policy 

The ProxySG permits you to define a rule-based administrative access policy. This policy is enforced 
when accessing: 

□ the Management Console through http or https 

□ the CLI through SSH when using password authentication 

□ the CLI through telnet 
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□ the CLI through the serial port if the secure serial port is enabled 

These policy rules can be specified either by using the VPM or by editing the Local policy file. Using 
policy rules, you can deny access, allow access without providing credentials, or require 
administrators to identify themselves by entering a username and password. If access is allowed, you 
can specify whether read-only or read-write access is given. You can make this policy contingent on IP 
address, time of day, group membership (if credentials were required), and many other conditions. 

Serial-console access is not controlled by policy rules. For maximum security to the serial console, 
physical access must be limited. 

SSH with RSA authentication also is not controlled by policy rules. You can configure several settings 
that control access: the enable password, the console ACL, and per-user keys configured through the 
Configuration>Services>SSH>SSH Client page. (If you use the CLI, SSH commands are under 

conf ig> services >ssh- console.) 

Defining Administrator Authentication and Authorization Policies 

The ProxySG uses CPL to define policies, including administrator, authentication, and authorization 
policies. CPL also allows you to give administrator privileges to users in any external authentication 
service. 

The following summarizes the steps required to define Administrator Authentication and 
Authorization policies on the ProxySG: 

□ (Optional) If you need to give administrative access to existing users or groups, create and 
configure the authentication realm. See Chapter 9: "Using Authentication Services" on page 339 
for details on configuring authentication realms. 

□ Define the policies in the appropriate policy file where you keep the <Admin> Layer layers and 
rules. 

□ Load the policy file on the ProxySG. 

When you define such policies, make sure you define them in the appropriate policy file(s). For more 
information on policy files and how they are used, see Chapter 14: "The Visual Policy Manager" on 
page 567. 

Defining Policies Using the Visual Policy Manager 

To define policies through the Management Console, use the Visual Policy Manager. When you use 
the VPM, policies are configured in CPL and saved in the VPM policy file. For examples of 
Administrator authentication or authorization policy CPL, continue with the next section. The VPM is 
described in detail in Chapter 14: "The Visual Policy Manager" on page 567. 

Defining Policies Directly in Policy Files 

To define policies manually, type CPL rules directly in one of the two policy files. Central or Local. 
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Important: Do not manually enter CPL rules directly into the VPM file. The file becomes 
corrupted. 



For specific information on creating policies within the policy files, refer to the Blue Coat ProxySG 
Content Policy Language Guide. 

Following are the CPL elements that can be used to define administrator policies for the ProxySG. 

To Define Administrator Policies by Editing a Policy File: 

1 . Open the policy file in a text editor. 

2. Define the policies, using the correct CPL syntax. 

3. Save the file. 

4. Load the policy file (see "Creating and Editing Policy Files" on page 556). 

Admin Transactions and <Admin> Layers 



Admin transactions execute <Admin> layers. Only a restricted set of conditions, properties, and actions 
are permitted in <Admin> layers. Table 8.3 lists the conditions permitted in the <Admin> layer: 

Table 8.3: <Admin> Layer Conditions 



<Admin> Network Connection Conditions 


client_address=ip_address 
[ . subnetmask] 


Tests for a match between ip address and the IP address of the 
client transaction source. 


proxy . port =number 


Tests for a match between number and the port number for which 
the request is destined. 


proxy. address =ip_address 


Tests for a match between ip address and the IP address of the 
network interface card for which the request is destined. 


proxy . card=number 


Tests for a match between number and the ordinal number 
associated with the network interface card for which the request is 
destined. 


<Admin> General Conditions 


condition=condition . label 


Tests if the specified defined condition is true. 


release . id= 


Tests the ProxySG release id. 


<Admin> Date/Time Conditions 


date [ .utc] = [date | date...date ] 


Tests for a match between date and the date timestamp associated 
with the source of the transaction, date specifies a single date of the 
form YYYY-MM-DD or an inclusive range, as in 
YYYY - MM - DD...YYYY - MM - DD. By default, date is calculated based on 
local time. To calculate year based on the Coordinated Universal 
Time, include the . utc qualifier 
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Table 8.3: <Admin> Layer Conditions (Continued) 



year [ .utc] = [year | year...year] 


Tests for a match between year and the year timestamp associated 
with the source of the transaction, year specifies a single Gregorian 
calendar year of the form YYYY or an inclusive range of years, as in 
YYYY...YYYY. By default, year is calculated based on local time. To 
calculate year based on the Coordinated Universal Time, include 
the .utc qualifier. 


month [. utc] = [month | 
month...month] 


Tests for a match between month and the month timestamp 
associated with the source of the transaction, month specifies a 
single Gregorian calendar month of the form MM or an inclusive 
range of months, as in MM...MM. By default, month is calculated based 
on local time. To calculate month based on the Coordinated 
Universal Time, include the .utc qualifier. 


weekday [. utc] = [number \ 
number. ..number ] 


Tests for a match between weekday and the weekday timestamp 
associated with the source of the transaction, weekday specifies a 
single day of the week (where Monday=l, Tuesday=2, and 
Sunday=7) or an inclusive range of weekdays, as in 
number. ..number. By default, weekday is calculated based on local 
time. To calculate weekday based on the Coordinated Universal 
Time, include the .utc qualifier. 


day [ .utc] = [ day \ day...day] 


Tests for a match between day and the day timestamp associated 
with the source of the transaction, day specifies a single Gregorian 
calendar day of the month of the form DD or an inclusive range of 
days, as in DD...DD. By default, day is calculated based on local time. 
To calculate day based on the Coordinated Universal Time, include 
the .utc qualifier. 


hour [. utc] = [hour | hour...hour ] 


Tests for a match between hour and the hour timestamp associated 
with the source of the transaction, hour specifies a single Gregorian 
hour of the form HH (00, 01, and so forth, through 23) or an inclusive 
range of hours, as in HH. . .HH. By default, hour is calculated based 
on local time. To calculate hour based on the Coordinated Universal 
Time, include the .utc qualifier. 


minute [. utc] = [minute | 
minute...minute ] 


Tests for a match between minute and the minute timestamp 
associated with the source of the transaction, minute specifies a 
single Gregorian minute of the form MM (00, 01, and so forth, 
through 59) or an inclusive range of minutes, as in MM.. .MM. By 
default, minute is calculated based on local time. To calculate minute 
based on the Coordinated Universal Time, include the .utc qualifier. 


time [. utc] = [ time | time...time] 


Tests for a match between time and the time timestamp associated 
with the source of the transaction, time specifies military time of the 
form TTTT (0000 through 2 3 5 9 ) or an inclusive range of times, as in 
TTTT...TTTT. By default, time is calculated based on local time. To 
calculate time based on the Coordinated Universal Time, include 
the .utc qualifier. 
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Table 8.3: <Admin> Layer Conditions (Continued) 



<Admin> Authorization Conditions 


attribute . name = value 


Tests if the current transaction is authorized in a RADIUS or LDAP 
realm, and if the authenticated user has the specified attribute with 
the specified value. This trigger is unavailable if the current 
transaction is not authenticated 


authenticated^ (yes | no} 


Tests if authentication was requested and the credentials could be 
verified. 


group =group_name 


If authenticate=yes, the group condition tests the source of the 
transaction for membership in the specified groupname. 


has attribute . name=boolean 


Tests if the current transaction is authorized in an LDAP realm and if 
the authenticated user has the specified LDAP attribute. 


realm =realm name 


If authenticate=yes, the realm condition tests the source of the 
transaction for membership in the specified realm name. 


user = username 


If authenticate=yes, the user condition tests the source of the 
transaction for the expected username. 


user . domain= 
windows domain name 


(This condition is IWA-realm specific.) If authenticate=yes, the 
user_domain condition tests whether the realm type is IWA and 
whether the domain component of the username is the expected 
domain name. 


<Admin> Read-only or Read-write Conditions 


admin access=read | write 


read tests whether the source of the transaction has read-only 
permission for the ProxySG console, write tests whether the source 
has read-write permission. 

When an Administrator logs into the CLI, the ProxySG executes an 
<Admin> transaction that includes the condition 
admin access=read. If the transaction is ultimately allowed (all 
conditions have been met), the user will have read-only access to 
configuration information through the CLI. Further, when that user 
executes the CLI enable command, or logs into the Management 
Console, the ProxySG executes an <Admin> transaction with 
admin access=write. If the transaction is allowed, the user will 
have read-write access within the CLI or the Management Console. 



Table 8.4 lists the properties permitted in the <Admin> layer: 
Table 8.4: <Admin> Layer Properties 



<Admin> Properties 


deny 


Refuse service to the source of the transaction. 


authenticate [realm name ) 


Requests authentication of the transaction source for the 
specified realm. 
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Table 8.4: <Admin> Layer Properties (Continued) 



authenticate . force ( ) 


If yes is specified then forces authentication even if the 
transaction is denied. This results in the user information 
being available for logging. If no, then early denial without 
authentication is possible. 


allow 


Permit further service to the source of the transaction. 


log . suppress . field-id ( ) 


Controls suppression of the specified field- id in all 
facilities 


log . suppress . field-id [log_list] ( ) 


Controls suppression of the specified field-id in the 
specified facilities. 


log . rewrite . field-id ( ) 


Controls rewrites of a specific log field in all facilities. 


log . rewrite . field-id [log list ] 
( ) 


Controls rewrites of a specific log field in a specified list of 
log facilities. 



Table 8.5 lists the actions permitted in the <Admin> layer: 
Table 8.5: <Admin> Layer Actions 



<Admin> Actions 


notify email ( ) 


Sends an e-mail notification to the list of recipients specified in the 
Event Log mail configuration when the transaction terminates. 


notify_snmp( ) 


The SNMP trap is sent when the transaction terminates. 



Example Policy Using CPL Syntax 

To authenticate users against an LDAP realm, use the following syntax in the Local Policy file: 
<admin> 

authenticate ( LDAP_Realm ) 

<admin> 

group= "cn=Administrators , cn=Groups , dc=bluecoat , dc=com" allow 

This authenticates users against the specified LDAP realm. If the users are successfully authenticated 
and belong to group Administrators, they are allowed to administer the ProxySG. 
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Section B: Controlling Access to the Internet and Intranet 

Once the ProxySG is secure, you can limit access to the Internet and intranet. It is possible to control 
access to the network without using authentication. You only need to use authentication if you want 
to use identity-based access controls. 

This section contains: 

□ "Using Authentication and Proxies" 

□ "Using SSL with Authentication and Authorization Services" 

□ "Creating a Proxy Layer to Manage Proxy Operations” 

Using Authentication and Proxies 

Authentication means that the ProxySG requires proof of user identity in order to make decisions 
based on that identity. This proof is obtained by sending the client (a browser, for example) a 
challenge — a request to provide credentials. Browsers can respond to different kinds of credential 
challenges: 

□ Proxy-style challenges — Sent from proxy servers to clients that are explicitly proxied. In HTTP, the 
response code is 407. 

Am authenticating explicit proxy server sends a proxy-style challenge (407/Proxy- Authenticate) 
to the browser. The browser knows it is talking to a proxy and that the proxy wants proxy 
credentials. The browser responds to a proxy challenge with proxy credentials 
(Proxy- Authorization: header). The browser must be configured for explicit proxy in order for it 
to respond to a proxy challenge. 

□ Origin-style challenges — Sent from origin content servers (OCS), or from proxy servers 
impersonating a OCS. In HTTP, the response code is 401 Unauthorized. 

In transparent proxy mode, the ProxySG uses the OCS authentication challenge (HTTP 401 and 
WWW-Authenticate) — acting as though it is the location from which the user initially requested a 
page. A transparent proxy, including a reverse proxy, must not use a proxy challenge, because the 
client might not be expecting it. 

Once the browser supplies the credentials, the ProxySG authenticates them. 

Understanding Authentication Modes 

You can control the way the ProxySG interacts with the client for authentication by controlling the 
authentication mode. The mode specifies the challenge type and the accepted surrogate credential. 



Note: Challenge type is the kind of challenge (for example, proxy or origin-ip-redirect) issued. 

Surrogate credentials are credentials accepted in place of the user's real credentials. 
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□ Auto: The default; the mode is automatically selected, based on the request. Auto can choose any 
of proxy, origin, origin-ip, or origin-cookie-redirect, depending on the kind of connection (explicit or 
transparent) and the transparent authentication cookie configuration. 



Note: When auto mode chooses origin-ip, as is the case with Windows SSO or Novell SSO 

authentication, any requests coming from the authenticated IP address are considered 
authenticated for the length of the cache duration. If multiple users often log in from the 
same IP address, a shorter realm cache duration than the default of 900 seconds or a 
different authentication mode are recommended. 



□ Proxy: The ProxySG uses an explicit proxy challenge. No surrogate credentials are used. This is the 
typical mode for an authenticating explicit proxy. In some situations proxy challenges do not 
work; origin challenges are then issued. 

If you have many requests consulting the back-end authentication authority (such as LDAP, 
RADIUS, or the BCAAA service), you can configure the ProxySG (and possibly the client) to use 
persistent connections. This dramatically reduces load on the back-end authentication authority 
and improves the all-around performance of the network. 



Important: Windows supports Kerberos authentication only to origin servers; proxy servers 

cannot participate. Therefore, explicit authentication modes are not compatible with 
Kerberos. However, because Internet Explorer automatically selects NTLM for an 
explicit challenge (where the browser is configured with the proxy as a proxy 
server), no special processing is required for explicit authentication. An origin 
redirect authentication mode, such as authenticate . mode 
(origin-cookie-redirect ) , can be used to obtain Kerberos authentication 
when using an explicit proxy if the browser is configured to bypass the proxy for 
the virtual URL. 



□ Proxy-1 P: The ProxySG uses an explicit proxy challenge and the client's IP address as a surrogate 
credential. Proxy-IP specifies an insecure forward proxy, possibly suitable for LANs of single-user 
workstations. In some situations proxy challenges do not work; origin challenges are then issued. 

□ Origin: The ProxySG acts like an OCS and issues OCS challenges. The authenticated connection 
serves as the surrogate credential. 

□ Origin-1 P: The ProxySG acts like an OCS and issues OCS challenges. The client IP address is used as 
a surrogate credential. Origin-1 P is used to support IWA authentication to the upstream device 
when the client cannot handle cookie credentials. This mode is primarily used for automatic 
downgrading, but it can be selected for specific situations. 

□ Origin-cookie: The ProxySG acts like an origin server and issues origin server challenges. A cookie 
is used as the surrogate credential. Origin-cookie is used in forward proxies to support 
pass-through authentication more securely than origin-ip if the client understands cookies. Only 
the HTTP and HTTPS protocols support cookies; other protocols are automatically downgraded 
to origin-ip. 
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This mode could also be used in reverse proxy situations if impersonation is not possible and the 
origin server requires authentication. 

□ Origin-cookie-redirect: The client is redirected to a virtual URL to be authenticated, and cookies are 
used as the surrogate credential. The ProxySG does not support origin-redirects with the 
CONNECT method. For forward proxies, only origin-*-redirect modes are supported for 
Kerberos/IWA authentication. (Any other mode uses NTLM authentication.) 



Note: During cookie-based authentication, the redirect to strip the authentication cookie from 

the URL is logged as a 307 (or 302) TCP_DENIED. 



□ Origin-1 P-redirect: The client is redirected to a virtual URL to be authenticated, and the client IP 
address is used as a surrogate credential. The ProxySG does not support origin-redirects with the 
CONNECT method. For forward proxies, only origin-*-redirect modes are supported for 
Kerberos/IWA authentication. (Amy other mode uses NTLM authentication.) 

□ SG2: The mode is selected automatically, based on the request, and uses the SGOS 2.x-defined 
rules. 

□ Form-IP: A form is presented to collect the user's credentials. The form is presented whenever the 
user's credential cache entry expires. 

□ Form-Cookie: A form is presented to collect the user's credentials. The cookies are set on the OCS 
domain only, and the user is presented with the form for each new domain. This mode is most 
useful in reverse proxy scenarios where there are a limited number of domains. 

□ Form-Cookie-Redirect: A form is presented to collect the user's credentials. The user is redirected to 
the authentication virtual URL before the form is presented. The authentication cookie is set on 
both the virtual URL and the OCS domain. The user is only challenged when the credential cache 
entry expires. 

□ Form-1 P-redirect: This is similar to form-ip except that the user is redirected to the authentication 
virtual URL before the form is presented. 



Important: Modes that use an IP surrogate credential are insecure: After a user has 

authenticated from an IP address, all further requests from that IP address are 
treated as from that user. If the client is behind a NAT, or on a multi-user system, this 
can present a serious security problem. 



The default value is auto . 

For more information on using authentication modes, see the Blue Coat ProxySG Content Policy 
Language Guide. 

Setting the Default Authenticate Mode Property 

Setting the authentication . mode property selects a challenge type and surrogate credential 
combination. In auto mode, explicit IWA uses connection surrogate credentials. In sg2 mode, explicit 
IWA uses IP surrogate credentials. 
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To Configure the IWA Default Authenticate Mode Settings 

At the (config) command prompt, enter the following commands: 

SGOS# (config) security default-authenticate-mode {auto | sg2 } 

Understanding Origin-Style Redirection 

Some authentication modes redirect the browser to a virtual authentication site before issuing the 
origin-style challenge. This gives the user feedback as to which credentials are required, and makes it 
possible to (but does not require) send the credentials over a secure connection. 

Since browser requests are transparently redirected to the ProxySG, the appliance intercepts the 
request for the virtual authentication site and issues the appropriate credential challenge. Thus, the 
challenge appears to come from the virtual site, which is usually named to make it clear to the user 
that ProxySG credentials are requested. 

If authentication is successful, the ProxySG establishes a surrogate credential and redirects the 
browser back to the original request, possibly with an encoded surrogate credential attached. This 
allows the ProxySG to see that the request has been authenticated, and so the request proceeds. The 
response to that request can also carry a surrogate credential. 

To provide maximum flexibility, the virtual site is defined by a URL. Requests to that URL (only) are 
intercepted and cause authentication challenges; other URLs on the same host are treated normally. 
Thus, the challenge appears to come from a host that in all other respects behaves normally. 



Note: Sharing the virtual URL with other content on a real host requires additional 

configuration if the credential exchange is over SSL. 



You can configure the virtual site to something that is meaningful for your company. The default, 
which requires no configuration, is www . cf auth . com. See "Configuring Transparent Proxy 
Authentication" on page 327 to set up a virtual URL for transparent proxy. 

Tip: Using CONNECT and Origin-Style Redirection 

You cannot use the CONNECT method with origin-style redirection or form redirect modes. An error 
message similar to the following is displayed: 

Cannot use origin-redirect for CONNECT method (explicit proxy of https URL) 

Instead, you can add policy to either bypass authentication on the CONNECT method, or use proxy 
authentication. For example: 

<proxy> 

allow http . method=CONNECT authenticate . mode (proxy) authenticate (ldap) 
allow authenticate (cert) authenticate .mode (origin-cookie-redirect) 

Selecting an Appropriate Surrogate Credential 

IP surrogate credentials are less secure than cookie surrogate credentials and should be avoided if 
possible. If multiple clients share an IP address (such as when they are behind a NAT firewall or on a 
multi-user system), the IP surrogate mechanism cannot distinguish between those users 
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Configuring Transparent Proxy Authentication 

The following sections provide general instructions on configuring for transparent proxy 
authentication. 

In addition to configuring transparent proxy authentication, you must also enable a transparent proxy 
port before the transparent proxy is functional. To enable a transparent proxy port, see "Section B: 
Creating and Editing Services" on page 160. 

To Set Transparent Proxy Options through the Management Console 
1. Select Configuration>Authentication>Transparent Proxy. 



Transparent Proxy 

- Transparent proxy options 



Method: @ Cookie 

Oip 



Cookie type: ® Session 
O Persistent 



Cookie TTL 
IP TTL 




minutes 

minutes 



- Global Virtual URL 

URL: [ www.cfauth.com/ 



Figure 8-3: Transparent Proxy Tab 



2. Select the transparent proxy method — Cookie-based or IP address-based. The default is Cookie. 

If you select Cookie, the Cookie Type radio buttons are available. Click either: Session, for cookies 
that are deleted at the end of a session, or Persistent, for cookies that remain on a client machine 
until the cookie TTL (Time To Live) is reached or the credentials cache is flushed. The default is 
Session. 



If you select Persistent Cookies, enter the Cookie TTL. If you choose IP address-based, enter the IP 
address TTL. The default for each is 15 minutes. 



Note: A value of 0 (zero) for the IP address TTL re-prompts the user for credentials once the 

specified cache duration for the particular realm has expired. 



For authentication modes that make use of IP surrogate credentials, once the IP address 
TTL expires the proxy re-challenges all client requests that do not contain credentials for 
which an IP surrogate credential cache entry previously existed. 



If at this point the client supplied a different set of credentials than previously used to 
authenticate — for which an entry in the user credential cache still exists — the proxy fails 
authentication. This is to prevent any another client to potentially gain network access by 
impersonating another user by supplying his or her credentials. However, once the user 
credential cache entry's TTL has expired, you can supply a different set of credentials than 
previously used for authentication. 
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Note: For authentication modes that make use of IP surrogate credentials, once the IP 

address TTL expires the proxy re-challenges all client requests that do not contain 
credentials for which an IP surrogate credential cache entry previously existed. 

If at this point the client supplied a different set of credentials than previously used to 
authenticate — for which an entry in the user credential cache still exists — the proxy 
fails authentication. This is to prevent any another client from potentially gaining 
network access by impersonating another user by supplying his or her credentials. 
Flowever, once the user credential cache entry's TTL expires, you can supply a 
different set of credentials than previously used for authentication. 



3. Select the Virtual URL. The default is www . cf auth . com. Blue Coat recommends you change the 
virtual hostname to something meaningful to you, preferably the IP address of the ProxySG, 
unless you are doing secure credentials over SSL. Using the IP address of the ProxySG enables 
you to be sure that the correct ProxySG is addressed in a cluster configuration. 

4. Click Apply. 

To Set Transparent Proxy Options through the CLI 

1. At the (config) command prompt, enter the following command: 

SGOS# (config) security transparent-proxy-auth method {cookie | ip} 

a. If you select cookie-based transparent proxy authentication, enter the following 
command to specify persistent cookies or cookies that persist for the current session only: 

SGOS# (config) security transparent-proxy-auth cookie {persistent | 
session} 

b. If you select persistent cookies, enter the following command to specify the minutes that 
the cookie persists: 

SGOS# (config) security transparent-proxy-auth time-to-live 
persistent-cookie minutes 

c. If you select IP-based transparent proxy authentication, enter the following command to 
specify that the user be re-prompted for credentials after the number of TTL minutes 
specified: 

SGOS# (config) security transparent-proxy-auth time-to-live ip minute 

A value of 0 (zero) for the IP address TTL re-prompts the user for credentials once the 
specified cache duration for the particular realm has expired. 

2. (Optional step for single ProxySG scenarios, only needed if specifying a different virtual URL than 
supplied by Blue Coat — www . cf auth . com) To specify the virtual URL for cookie-based 
authentication, enter the following command: 

SGOS# (config) security transparent-proxy-auth cookie virtual-url url 

3. (Optional, if you choose cookie-based) Add the virtual host domain to the DNS service for your 
organization so that browsers, when redirected to the virtual URL, can resolve the hostname in 
the URL. (If you use the virtual hostname provided by Blue Coat — www. cf auth . com — you do not 
need to add the hostname to the DNS service.) 
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Using SSL with Authentication and Authorization Services 

Blue Coat recommends that you use SSL during authentication to secure your user credentials. Blue 
Coat now supports SSL between the client and the ProxySG and between the ProxySG to LDAP and 
IWA authentication servers. 

Using SSL Between the Client and the ProxySG 

To configure SSL for to use origin-cookie-redirect or origin-ip-redirect challenges, you must: 

□ Specify a virtual URL with the HTTPS protocol (for example, https : / / virtual_address. 
n Create a keyring and certificate on the ProxySG. 

□ Create an HTTPS service to run on the port specified in the virtual URL and to use the keyring 
you just created. 



Note: You can use SSL between the client and the ProxySG for origin-style challenges on 

transparent and explicit connections (SSL for explicit proxy authentication is not 
supported). 



In addition, if you use a forward proxy, the challenge type must use redirection; it cannot be 
an origin or origin-ip challenge type. 

When redirected to the virtual URL, the user is prompted to accept the certificate offered by the 
ProxySG (unless the certificate is signed by a trusted certificate authority). If accepted, the 
authentication conversation between the ProxySG and the user is encrypted using the certificate. 



Note: If the hostname does not resolve to the IP address of the ProxySG, then the network 

configuration must redirect traffic for that port to the appliance. Also, if you use the IP 
address as the virtual hostname, you might have trouble getting a certificate signed by a 
CA-Certificate authority (which might not be important). 



For information on creating a keyring and a certificate, see "Section B: Configuring HTTPS Reverse 
Proxy" on page 270. 

You can use SSL between the ProxySG and IWA and LDAP authentication servers. For more 
information, see Chapter 9: "Using Authentication Services" on page 339. 
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Creating a Proxy Layer to Manage Proxy Operations 

Once hardware configuration is complete and the system configured to use transparent or explicit 
proxies, use CPL or VPM to provide on-going management of proxy operations. 

Using CPL 

Below is a table of all commands available for use in proxy layers of a policy. If a condition, property, 
or action does not specify otherwise, it can be used only in < Proxy > layers. For information on 
creating effective CPL, refer to the Blue Coat ProxySG Content Policy Language Guide. 

Table 8.6: <Proxy> Layer Conditions 



<Proxy> Layer Conditions 


Meaning 


admin . access = 


Tests the administrative access requested by the current transaction. Can 
also be used in <Admin> layers. 


attribute . name= 


Tests if the current transaction is authenticated in a RADIUS or LDAP 
realm, and if the authenticated user has the specified attribute with the 
specified value. Can also be used in <Admin> layers. 


authenticated= 


Tests if authentication was requested and the credentials could be verified; 
otherwise, false. Can also be used in <Admin> layers. 


bitrate= 


Tests if a streaming transaction requests bandwidth within the specified 
range or an exact match. Can also be used in < Cache > layers. 


category^ 


Tests if the content categories of the requested URL match the specified 
category, or if the URL has not been categorized. Can also be used in 
< Cache > layers. 


client_address= 


Tests the IP address of the client. Can also be used in <Admin> layers. 


client . connection . 
negotiated_cipher= 


Test the cipher suite negotiated with a securely connected client. Can also 
be used in <Exception> layers. 


client . connection . 
negotiated_cipher . 
strength= 


Test the cipher strength negotiated with a securely connected client. Can 
also be used in <Exception> layers. 


client .host= 


Test the hostname of the client (obtained through RDNS). Can also be used 
in <Admin>, <Forward>, and <Exception> layers. 


client . host . has name= 


Test the status of the RDNS performed to determine 'client. host 1 . Can also 
be used in <Admin>, <Forward>, and <Exception> layers. 


client_protocol= 


Tests true if the client transport protocol matches the specification. Can also 
be used in <Exception> layers. 


condition= 


Tests if the specified defined condition is true. Can be used in all layers. 


console_access= 


(This trigger was formerly admin=yes | no.) Tests if the current request is 
destined for the admin layer. Can also be used in < Cache > and 
<Exception> layers. 
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content management= 


(This trigger was formerly content admin=yes | no.) Tests if the current 
request is a content-management transaction. Can also be used in 
<Exception> and <Forward> layers. 


date [ .utc] = 


Tests true if the current time is within the startdate..enddate range, 
inclusive. Can be used in all layers. 


day= 


Tests if the day of the month is in the specified range or an exact match. 
Can be used in all layers. 


exception . id= 


Indicates that the requested object was not served, providing this specific 
exception page. 

Can also be used in <Exception> layers. 


ftp .method= 


Tests ftp request methods against any of a well-known set of FTP methods. 
Can also be used in <Cache> and <Exception> layers. 


group= 


Tests if the authenticated condition is set to yes, the client is authenticated, 
and the client belongs to the specified group. Can also be used in <Admin> 
layers. 


has attribute . name= 


Tests if the current transaction is authenticated in an LDAP realm and if the 
authenticated user has the specified LDAP attribute. Can also be used in 
<Admin> layers. 


hour= 


Tests if the time of day is in the specified range or an exact match. Can be 
used in all layers. 


http.method= 


Tests HTTP request methods against any of a well known set of HTTP 
methods. Can also be used in <Cache> and <Exception> layers. 


http . method . regex= 


Test the HTTP method using a regular expression. Can also be used in 
<Exception> layers. 


http. request line.regex= 


Test the HTTP protocol request line. Can also be used in <Exception> 
layers. 


http . request . version= 


Tests the version of HTTP used by the client in making the request to the 
ProxySG. Can also be used in < Cache > and <Exception> layers. 


http . response_code= 


Tests true if the current transaction is an HTTP transaction and the 
response code received from the origin server is as specified. Can also be 
used in <Cache> and <Exception> layers. 


http . response . version= 


Tests the version of HTTP used by the origin server to deliver the response 
to the ProxySG. Can also be used in <Cache> and <Exception> layers. 


http . transparent 
authentication 


This trigger evaluates to true if HTTP uses transparent proxy 
authentication for this request. Can also be used in < Cache > and 
<Exception> layers. 


im. buddy id= 


Tests the buddy id associated with the IM transaction. Can also be used 
in <Exception> layers. 
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im.chat room. conference= 


Tests whether the chat room associated with the transaction has the 
conference attribute set. Can also be used in <Exception> layers. 


im.chat room.id= 


Tests the chat room ID associated with the transaction. Can also be used in 
<Exception> layers. 


im.chat room. invite 
only= 


Tests whether the chat room associated with the transaction has the 
invite only attribute set. Can also be used in <Exception> layers. 


im.chat room.type= 


Tests whether the chat room associated with the transaction is public or 
private. Can also be used in <Exception> layers. 


im.chat room. member = 


Tests whether the chat room associated with the transaction has a member 
matching the specified criterion. Can also be used in <Exception> layers. 


im.chat room. voice 
enabled= 


Tests whether the chat room associated with the transaction is voice 
enabled. Can also be used in <Exception> layers. 


im. client= 


Test the type of IM client in use. Can also be used in < Exceptions, 
< Forwards, and < Caches layers. 


im . f ile . extension= 


Tests the file extension. Can also be used in <Exceptions layers. 


im . f ile . name= 


Tests the file name (the last component of the path), including the 
extension. Can also be used in <Exceptions layers. 


im . f ile . path= 


Tests the file path against the specified criterion. Can also be used in 
<Exceptions layers. 


im. file . size= 


Performs a signed 64-bit range test. Can also be used in <Exception> 
layers. 


im. message . reflected 


Test whether IM reflection occurred. Can also be used in <Exception> 
and <Forward> layers. 


im . message . route= 


Tests how the IM message reaches its recipients. Can also be used in 
<Exception> layers. 


im. message . size= 


Performs a signed 64-bit range test. Can also be used in <Exception> 
layers. 


im . message . text . 
substring= 


Performs a signed 64-bit range test. Can also be used in <Exception> 
layers. 


im. message . opcode= 


Tests the value of an opcode associated with an im . method of 
send unknown or receive unknown. 


im . message . type= 


Tests the message type. Can also be used in <Exception> layers. 


im . method= 


Tests the method associated with the IM transaction. Can also be used in 
<Cache> and <Exception> layers. 


im.user id= 


Tests the user_id associated with the IM transaction. Can also be used in 
<Exception> layers. 
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live= 


Tests if the streaming content is a live stream. Can also be used in <Cache> 
layers. 


minute= 


Tests if the minute of the hour is in the specified range or an exact match. 
Can be used in all layers. 


month= 


Tests if the month is in the specified range or an exact match. Can be used 
in all layers. 


proxy. address= 


Tests the IP address of the network interface card (NIC) on which the 
request arrives. Can also be used in <Admin> layers. 


proxy . card= 


Tests the ordinal number of the network interface card (NIC) used by a 
request. Can also be used in <Admin> layers. 


proxy . port= 


Tests if the IP port used by a request is within the specified range or an 
exact match. Can also be used in <Admin> layers. 


raw url 


Test the value of the raw request URL. Can also be used in <Exception> 
layers. 


raw url . host 


Test the value of the 'host' component of the raw request URL. Can also be 
used in <Exception> layers. 


raw url . path 


Test the value of the 'path' component of the raw request URL. Can also be 
used in <Exception> layers. 


raw url . pathquery 


Test the value of the 'path and query' component of the raw request URL. 
Can also be used in <Exception> layers. 


raw url . port 


Test the value of the 'port' component of the raw request URL. Can also be 
used in <Exception> layers. 


raw url. query 


Test the value of the 'query' component of the raw request URL. Can also 
be used in < Exceptions layers. 


realm= 


Tests if the authenticated condition is set to yes, the client is authenticated, 
and the client has logged into the specified realm, an also be used in 
<Admin> layers. 


release . id= 


Tests the ProxySG release ID. Can be used in all layers. 


request . header_address . 
header name= 


Tests if the specified request header can be parsed as an IP address. Can 
also be used in <Cache> layers. 


request . header . header 
name= 


Tests the specified request header ( header name) against a regular 
expression. Can also be used in < Cache > layers. 


request . header . header 
name . count 


Test the number of header values in the request for the given header_name. 
Can also be used in <Exception> layers. 


request . header . header 
name . length 


Test the total length of the header values for the given header_name. Can 
also be used in <Exception> layers. 
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request . header . Ref erer . 
url . host . has_name= 


Test whether the Referer URL has a resolved DNS hostname. Can also be 
used in <Exception> layers. 


request . header . Ref erer . 
url. is absolute 


Test whether the Referer URL is expressed in absolute form. Can also be 
used in <Exception> layers. 


request. raw headers, 
count 


Test the total number of HTTP request headers. Can also be used in 
<Exception> layers. 


request. raw headers, 
length 


Test the total length of all HTTP request headers. Can also be used in 
<Exception> layers. 


request . raw headers . 
regex 


Test the value of all HTTP request headers with a regular expression. Can 
also be used in <Exception> layers. 


request. x header . header 
name . count 


Test the number of header values in the request for the given 
header name. Can also be used in <Exception> layers. 


request. x header . header 
name . length 


Test the total length of the header values for the given header name. Can 
also be used in <Exception> layers. 


response . header . header 
name= 


Tests the specified response header (header name) against a regular 
expression. Can also be used in < Cache > layers. 


response. x header. 
header name= 


Tests the specified response header (header name) against a regular 
expression. Can also be used in < Caches layers. 


server url [ . case 
sensitive | .no_lookup] = 


Tests if a portion of the requested URL exactly matches the specified 
pattern. Can also be used in < Forwards layers. 


socks . accelerated= 


Controls the SOCKS proxy handoff to other protocol agents. 


socks .method= 


Tests the protocol method name associated with the transaction. Can also 
be used in cCaches and <Exceptions layers. 


socks . version= 


Switches between SOCKS 4/4a and 5. Can also be used in <Exceptions 
and < Forwards layers. 


streaming . content= 


(This trigger has been renamed from streaming.) Can also be used in 
cCaches, cExceptions, and <Forwards layers. 


time = 


Tests if the time of day is in the specified range or an exact match. Can be 
used in all layers. 


tunneled= 




url . domain= 


Tests if the requested URL, including the domain-suffix portion, matches 
the specified pattern. Can also be used in < Forwards layers. 


url . extension= 


Tests if the filename extension at the end of the path matches the specified 
string. Can also be used in <Forwards layers. 


url . host= 


Tests if the host component of the requested URL matches the IP address or 
domain name. Can also be used in <Forwards layers. 
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url. host. has name 


Test whether the request URL has a resolved DNS hostname. Can also be used in 
<Exception> layers 


url . is_absolute 


Test whether the request URL is expressed in absolute form. Can also be 
used in <Exception> layers 


url. host. is numeric= 


This is true if the URL host was specified as an IP address. Can also be used 
in <Forward> layers. 


url . host . no name= 


This is true if no domain name can be found for the URL host. Can also be 
used in <Forward> layers. 


url . host . regex= 


Tests if the specified regular expression matches a substring of the domain 
name component of the request URL. Can also be used in <Forward> 
layers. 


url . host . suf f ix= 


Can also be used in <Forward> layers. 


url . path= 


Tests if a prefix of the complete path component of the requested URL, as 
well as any query component, matches the specified string. Can also be 
used in <Forward> layers. 


url . path . regex= 


Tests if the regex matches a substring of the path component of the request 
URL. Can also be used in <Forward> layers. 


url . port= 


Tests if the port number of the requested URL is within the specified range 
or an exact match. Can also be used in <Forward> layers. 


url . query . regex= 


Tests if the regex matches a substring of the query string component of the 
request URL. Can also be used in <Forward> layers. 


url . regex= 


Tests if the requested URL matches the specified pattern. Can also be used 
in <Forward> layers. 


url . scheme= 


Tests if the scheme of the requested URL matches the specified string. Can 
also be used in <Forward> layers. 


user= 


Tests the authenticated user name of the transaction. Can also be used in 
<Admin> layers. 


user . domain= 


Tests if the authenticated condition is set to yes, the client is authenticated, 
the logged-into realm is an IWA realm, and the domain component of the 
user name is the specified domain. Can also be used in <Admin> layers. 


weekday= 


Tests if the day of the week is in the specified range or an exact match. Can 
be used in all layers. 


year= 


Tests if the year is in the specified range or an exact match. Can be used in 
all layers. 
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<Proxy> Layer Properties 


Meaning 


action . action label ( ) 


Selectively enables or disables a specified define action block. Can also be 
used in < Cache > layers. 


allow 


Allows the transaction to be served. Can be used in all layers except 
<Exception> and <Forward> layers. 


always verify ( ) 


Determines whether each request for the objects at a particular URL must 
be verified with the origin server. 


authenticate ( ) 


Identifies a realm that must be authenticated against. Can also be used in 
<Admin> layers. 


authenticate . force ( ) 


Either disables proxy authentication for the current transaction (using the 
value no) or requests proxy authentication using the specified 
authentication realm. Can also be used in <Admin> layers. 


authenticate . form ( ) 


When forms-based authentication is in use, authenticate.form ( ) selects the 
form used to challenge the user. 


authenticate . mode (auto) 
authenticate . mode (sg2) 


Setting the authentication.mode property selects a challenge type and 
surrogate credential combination. In auto mode, explicit IWA uses 
connection surrogate credentials. In sg2 . mode, explicit IWA uses IP 
surrogate credentials. 


authenticate . redirect 
stored_requests 


Sets whether requests stored during forms-based authentication can be 
redirected if the upstream host issues a redirecting response. 


bypass_cache ( ) 


Determines whether the cache is bypassed for a request. 


check authorization ( ) 


In connection with CAD (Caching Authenticated Data) and CPAD 
(Caching Proxy Authenticated Data) support, 

check authorization ( ) is used when you know that the upstream 
device will sometimes (not always or never) require the user to 
authenticate and be authorized for this object. Can also be used in 
< Cache > layers. 


delete on abandonment ( ) 


If set to yes, then if all clients requesting an object close their connections 
prior to the object being delivered, the object fetch from the origin server is 
abandoned. Can also be used in < Cache > layers. 


deny 


Denies service. Can be used in all layers except <Exception> and 
<Forward> layers. 


dynamic bypass ( ) 


Used to indicate that a particular transparent request should not be 
handled by the proxy, but instead be subjected to our dynamic bypass 
methodology. 


exception ( ) 


Indicates not to serve the requested object, but instead serve this specific 
exception page. 

Can be used in all layers except <Exception> layers. 
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ftp. server connection ( ) 


Determines when the control connection to the server is established. 


ftp. welcome banner ( ) 


Sets the welcome banner for a proxied FTP transaction. 


http . client . recv. timeout 


Sets the socket timeout for receiving bytes from the client. 


http . request .version ( ) 


The http . request . version ( ) property sets the version of the HTTP 
protocol to be used in the request to the origin content server or upstream 
proxy. Can also be used in < Cache > layers. 


http . response . parse_meta_ 
tag . 

Cache-Control ( ) 


Controls whether the 'Cache-Control' META Tag is parsed in an HTML 
response body. Can also be used in < Cache > layers. 


http . response . parse meta 
tag. Expires 


Controls whether the 'Expires' META Tag is parsed in an HTML response 
body. Can also be used in <Cache> layers. 


http . response . parse_meta_ 
tag. Pragma . no-cache 


Controls whether the 'Pragma: no-cache' META Tag is parsed in an HTML 
response body. Can also be used in < Cache > layers. 


http . response .version ( ) 


The http . response . version ( ) property sets the version of the 
HTTP protocol to be used in the response to the client's user agent. 


http . server . recv . 
timeout ( ) 


Sets the socket timeout for receiving bytes from the upstream host. Can 
also be used in <Forward> layers. 


im. block encryption 


Prevents the encryption of AOL IM messages by modifying messages 
during IM login time. 


im. reflect 


Sets whether IM reflection should be attempted. 


im. strip attachments ( ) 


Determines whether attachments are stripped from IM messages. 


im. transport 


Sets the type of upstream connection to make for IM traffic. 


log . suppress . field- id ( ) 


The log . suppress . field-id ( ) controls suppression of the specified 
field-id in all facilities (individual logs that contain all properties for that 
specific log in one format). Can be used in all layers. 


log . suppress . field-id 
[ log_list ] ( ) 


The log . suppress . field-id [log_lis t] ( ) property controls 
suppression of the specified field-id in the specified facilities. Can be used 
in all layers. 


log . rewrite . field-id ( ) 


The log . rewrite . field- id ( ) property controls rewrites of a specific 
log field in all facilities. Can be used in all layers. 


log . rewrite .field-id 
[log_lis t] ( ) 


The log . rewrite . field-id [ log list] { ) property controls 
rewrites of a specific log field in a specified list of log facilities. Can be used 
in all layers. 


reflect_ip( ) 


Determines how the client IP address is presented to the origin server for 
explicitly proxied requests. Can also be used in <Forward> layers. 


request . filter service ( ) 


Websense is the built in service name for the off -box content filtering 
service. Can also be used in <Cache> layers. 
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request . icap_service ( } 


Determines whether a request from a client should be processed by an 
external ICAP service before going out. 


shell .prompt 


Sets the prompt for a proxied Shell transaction. 


shell. realm banner 


Sets the realm banner for a proxied Shell transaction. 


shell . welcome banner 


Sets the welcome banner for a proxied Shell transaction. 


socks . accelerate ( ) 


The socks . accelerate property controls the SOCKS proxy handoff to 
other protocol agents. 


socks . authenticate ( ) 


The same realms can be used for SOCKS proxy authentication as can be 
used for regular proxy authentication. 


socks . authenticate . 
force ( ) 


The socks . authenticate . force ( ) property forces the realm to be 
authenticated through SOCKS. 



Table 8.8: <Proxy> Layer Actions 



<Proxy> Layer Actions 


Meaning 


log_message ( ) 


Writes the specified string to the ProxySG event log. Can be used in all 
layers except <Admin>. 


notify email ( ) 


Sends an e-mail notification to the list of recipients specified in the Event 
Log mail configuration. Can be used in all layers. 


notify_snmp( ) 


The SNMP trap is sent when the transaction terminates. Can be used in all 
layers. 


redirect ( ) 


Ends the current HTTP transaction and returns an HTTP redirect response 
to the client. 


transform 


Invokes the active content or URL rewrite transformer. 
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Determining and configuring the type of security (such as LDAP, local list, and IWA) to implement on 
your network (authorization) is a critical part of managing enterprise security 

Understanding Realms 

The ProxySG provides a flexible authentication architecture that supports multiple services with 
multiple backend servers (for example, LDAP directory servers together with NT domains with no 
trust relationship) within each authentication scheme with the introduction of the realm. 

A realm authenticates and authorizes users for access to ProxySG services using either explicit proxy or 
transparent proxy mode, discussed in "Configuring Proxies" on page 181. 

Multiple authentication realms can be used on a single ProxySG. Multiple realms are essential if the 
enterprise is a managed provider or the company has merged with or acquired another company. 
Even for companies using only one protocol, multiple realms might be necessary, such as the case of a 
company using an LDAP server with multiple authentication boundaries. You can use realm 
sequencing to search the multiple realms all at once. 

A realm configuration includes: 

□ Realm name. 

□ Authentication service — (IWA, LDAP, RADIUS, Local, Certificate, Sequences, Netegrity 
SiteMinder®, Oracle® COREid™, Policy Substitution, Novell® SSO, XML, Windows® SSO). 

□ External server configuration — Backend server configuration information, such as host, port, and 
other relevant information based on the selected service. 

□ Authentication schema — The definition used to authenticate users. 

□ Authorization schema — The definition used to authorize users for membership in defined groups 
and check for attributes that trigger evaluation against any defined policy rules. 

□ One-time passwords are supported for RADIUS realms only. 

SSL Between the ProxySG and the Authentication Server 

SSL communication between the ProxySG and LDAP and IWA authentication servers is supported. In 
addition, you can also use SSL between the client and the ProxySG. For more information on using 
SSL between the client and the ProxySG, see "Using SSL Between the Client and the ProxySG" on 
page 329. 

Configuring a realm to use SSL between the ProxySG and the authentication server is performed on a 
per-realm basis. Part of the SSL configuration is specifying whether to verify the server's certificate. If 
the server certificate is to be verified, then the server's certificate must be signed by a Certificate 
Authority that the ProxySG trusts, and the common name in the server certificate must match the 
server host as specified in the realm configuration. 
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The realms use the default SSL client defined on the ProxySG for SSL communications to the 
authentication servers. 



Note: If the browser is configured for on-line checking of certificate revocation, the status check 

must be configured to bypass authentication. 



The chapter contains the following sections: 

□ "Section A: IWA Realm Authentication and Authorization" 

□ "Section B: Windows Single Sign-on Authentication" 

□ "Section C: LDAP Realm Authentication and Authorization" 

□ "Section D: Novell Single Sign-on Authentication and Authorization" 

□ "Section E: RADIUS Realm Authentication and Authorization" 

□ "Section F: Local Realm Authentication and Authorization" 

□ "Section G: Certificate Realm Authentication" 

□ "Section H: Netegrity SiteMinder" 

□ "Section I: Oracle COREid" 

□ "Section J: Using XML Realms" 

□ "Section K: Policy Substitution Realm" 

□ "Section L: Sequence Realm Authentication" 

□ "Section M: Forms-Based Authentication" 

□ "Section N: Managing the Credential Cache" 
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Section A: IWA Realm Authentication and Authorization 

Integrated Windows Authentication (IWA) is an authentication mechanism available on Windows 
networks. (The name of the realm has been changed from NTLM to IWA.) 

IWA is a Microsoft-proprietary authentication suite that allows Windows clients (running on 
Windows 2000 and higher) to automatically choose between using Kerberos and NTLM 
authentication challenge/ response, as appropriate. When an IWA realm is used and a resource is 
requested by the client from the SG appliance, the appliance contacts the client's domain account to 
verify the client's identity and request an access token. The access token is generated by the domain 
controller (in case of NTLM authentication) or a Kerberos server (in the case of Kerberos 
authentication) and passed to (and if valid, accepted by) the SG appliance. 

Refer to the Microsoft Web site for detailed information about the IWA protocol. 

This section discusses the following topics: 

□ "How Blue Coat Works with IWA" 

□ "Creating an IWA Realm" 

□ "IWA Servers" 

□ "Defining IWA Realm General Properties" 

□ "Creating the CPL" 

How Blue Coat Works with IWA 

The server side of the Kerberos or NTLM authentication exchange is handled by the Blue Coat 
Authentication and Authorization Agent (BCAAA). 

A single BCAAA service can support multiple ProxySG Appliances; however, the service starts a 
processor agent for each realm that only handles authentication requests coming from that particular 
realm. 



BCAAA must be installed on a domain controller or member server. If the server where the BCAAA 
service is installed and its domain have a trust relationship with other domains, the user is 
authenticated automatically by the other domains. 

For a server to participate in an IWA Kerberos authentication exchange, it must share a secret with the 
Kerberos server (called a KDC) and have registered an appropriate Service Principal Name. 



For instructions on installing the BCAAA service and configuring a Service Principal Name, see 
Appendix A: "Using the Authentication/ Authorization Agent" on page 1021. 
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Creating an IWA Realm 

To create an IWA realm, you must provide at least the primary host of the IWA server for that realm. 

To Create an IWA Realm through the Management Console 
1. Select Configuration>Authentication>IWA>IWA Realms. 



IWA Realms | IWA Servers | IWA General 

r IWA Realms 




Figure 9-1 : IWA Realms Tab 
2. Click New; the Add IWA Realm dialog displays. 



Add IWA Realm 



Realm name: 




Realm Configuration • 
Primary server host: 



Port: 16101 



Other realm configuration parameters have been set to default values. 

OK ] [ Cancel ] 

Figure 9-2: Add IWA Realm 

3. In the Realm name field, enter a realm name. The name can be 32 characters long and composed of 
alphanumeric characters and underscores. The name must start with a letter. 

4. Identify the primary server host for the machine running BCAAA. You must enter a valid host or 
an error message is generated. 

5. (Optional) The default port is 16101. You can change the port number if the primary server is 
listening on a different port. 

6. Click OK; click Apply. 
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IWA Servers 

Once you create an IWA realm, you can use the IWA Servers page to change the current default 
settings. 

1. Select Configuration>Authentication>IWA>IWA Servers. 



IWA Realms IWA Servers | IWA General 



Realm name: 


IWA_1 


V 


5crv 






Primary server host: 


10.9.17.159 


Port: 16101 



Alternate server host: I Port: I 16101 | 



- SSL Options 

IH Enable SSL Verify server certificate 

Timeout request after | 60 seconds 

Figure 9-3: IWA Servers Tab 

2. From the Realm Name drop-down list, select the IWA realm for which you want to change server 
properties. 

3. You must have defined at least one IWA realm (using the IWA Realms page) before attempting to 
set IWA server properties. If the message Realms must be added in the IWA Realms tab 
before editing this tab is displayed in red at the bottom of this page, you do not currently 
have any IWA realms defined 

4. Specify the host and port for the primary IWA server. The default port is 16101. 

5. (Optional) Specify the host and port for the alternate IWA server. The default port is 16101. 

6. (Optional) Under SSL Options, click the SSL enable checkbox to enable SSL. 

7. (Optional) By default, if SSL is enabled, the BCAAA certificate is verified. If you do not want to 
verify the BCAAA certificate, deselect this checkbox. 

8. In the Timeout Request field, type the number of seconds the ProxySG allows for each request 
attempt before timing out. (The default request timeout is 60 seconds.) 

9. Click Apply. Repeat the above steps for additional IWA realms, up to a total of 40. 

To Create and Define an IWA Realm through the CLI 

1. At the (config) prompt, enter the following command to create an IWA realm: 

SGOS# (config) security IWA create-realm realm_name primary_host [primary_port] 



where: 



realm name 


The name of the IWA realm. 


primary host 


The host for the primary IWA server. 
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primary_port 



The port for the primary IWA server. The default port is 16101. 



2. To redefine the IWA realm configuration for the realm you just created, enter the following 
commands: 

SGOS# (config) security IWA edit-realm realm_name 

SGOS# (config IWA realm_name ) primary- server primary_host [primary_por t] 

and optionally, 

SGOS# (config IWA realm_name ) alternate-server alternate_host [ alternate_port ] 



where: 



primary host 


The host for the primary IWA server. 


primary port 


The port for the primary IWA server. The default port is 16101. 


alternate host 


The host for the alternate IWA server. 


alternate port 


The port for the alternate IWA server. The default port is 16101. 



3. To enable SSL for this realm and to have the BCAAA certificate verified, enter: 

SGOS# (config IWA realm_name ) ssl enable 

SGOS# (config IWA realm_name ) ssl-verify-server enable 



Note: The ssl-verify-server command in authentication is not overridden by the CPL 

property server . certificate .validate or the forwarding hosts ssl-verify-server 
command. 
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Defining IWA Realm General Properties 

The IWA General tab allows you to specify the display name, whether to support Basic and IWA 
credentials, the credential cache duration and a virtual URL. 

To Configure General Settings through the Management Console 

1. Select Configuration>Authentication>IWA>IWA General. 



IWA Realms 


IWA Servers 


IWA General 




Realm name: 


IWA_1 




V 










Display name: 


IWA _1 







[71 Allow Basic credentials 
[7] Allow NTLM credentials 

[71 Allow Kerberos credentials 
Cache credentials 900 seconds 

r Virtual URL 

URL: 

Figure 9-4: IWA General Tab 

2. From the Realm Name drop-down list, select the IWA realm for which you want to change 
properties. 



Note: You must have defined at least one IWA realm (using the IWA Realms tab) before 

attempting to set IWA general properties. If the message Realms must be added in the 
IWA Realms tab before editing this tab is displayed in red at the bottom of this 
page, you do not currently have any IWA realms defined. 



3. If needed, change the IWA realm display name. The default value for the display name is the 
realm name. The display name cannot be longer than 128 characters and it cannot be null. 

4. You can enable or disable support for Basic credentials in the realm by selecting or deselecting the 
Allow Basic credentials checkbox 

At least one Basic or NTLM/Kerberos credential must be enabled. Note that Basic credentials 
cannot be disabled in the IWA realm if the IWA realm is part of a sequence realm but is not the 
first realm in the sequence with try IWA authentication only once enabled. 

You can disable both NTLM and Kerberos credentials, leaving a realm that collects plaintext 
credentials but validates them against a Windows domain. 
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Important: The configuration of the realm can have significant security implications. If an IWA 

realm accepts Basic credentials, the client can automatically downgrade to sending 
the password in the clear. Similarly, the client can use NTLM instead of Kerberos. 



5. (Optional) You can enable or disable support for NTLM credentials in the realm by selecting or 
deselecting the Allow NTLM credentials checkbox. You can only enable support for Kerberos 
credentials in the realm if support for NTLM credentials has been enabled. 

6. (Optional) You can enable or disable support for Kerberos credentials in the realm by selecting or 
deselecting the Allow Kerberos credentials. You can only enable support for Kerberos credentials 
in the realm if support for NTLM credentials has been enabled. 

7. Specify the length of time, in seconds, that user and administrator credentials received from the 
IWA server are cached. Credentials can be cached for up to 3932100 seconds. The default cache 
duration is 900 seconds (15 minutes). 



Note: If you specify 0, traffic is increased to the IWA server because each authentication request 

generates an authentication and authorization request to the server. 



8. In the Virtual URL field, enter the URL to redirect to when the user needs to be challenged for 
credentials if using a redirecting authenticate. mode. 



Note: The virtual URL is not involved if the challenge does not redirect. 



You can specify a virtual URL based on the individual realm. For more information on the virtual 
URL, see "Understanding Origin-Style Redirection" on page 326. 

When NTLM is in use, requests to the virtual URL must be sent to the proxy. This can be done 
either by transparent redirection or by making the virtual URL hostname resolve to an IP address 
of the proxy. 

When Kerberos is in use: 

• The virtual URL hostname must be part of the Kerberos realm (this is using the term realm in 
the Kerberos sense, not the ProxySG sense). 

• For a forward proxy, this hostname should be added to the DNS server for the same domain 
as the Kerberos protected resources so that requests for this address go directly to the 
ProxySG. 

In both NTLM and Kerberos, if single-signon is desired, then the virtual URL hostname must 
have no dots and must not be proxied by the browser. The client must be able to resolve this 
hostname to an IP address of the proxy. 

9. Click Apply. 
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To Configure General Settings through the CLI 

At the (conf ig) command prompt, enter the following commands to configure general settings: 

SGOS# (config IWA realm_name ) cache -duration seconds 
SGOS# (config IWA realm_name ) credentials-basic enable | disable 
SGOS# (config IWA realm_name ) credentials-NTLM enable | disable 
SGOS# (config IWA realm_name) credentials-kerberos enable | disable 

SGOS# (config IWA realm_name ) display-name name 
SGOS# (config IWA realm_name ) virtual-url URL 



where: 



cache -duration 


seconds 


Specifies the length of time in seconds that user and 
administrator credentials received from the IWA server are 
cached. Credentials can be cached for up to 3932100 seconds. 
The default value is 90 0 seconds (15 minutes). 


credentials- 

basic 


enable | 
disable 


Enables or disables Basic credential support. 


credentials- 

kerberos 


enable | 
disable 


Enables or disables Kerberos credential support. 


credentials- 

ntlm 


enable | 
disable 


Enables or disables NTLM credential support. 


display-name 


name 


The default value for the display name is the realm name. The 
display name cannot be longer than 128 characters and it 
cannot be null. 


virtual-url 


URL 


The URL to redirect to when the user needs to be challenged for 
credentials. 

When NTLM is in use, requests to the virtual URL must be sent 
to the proxy. This can be done either by transparent redirection 
or by making the virtual URL hostname resolve to an IP 
address of the proxy. 

When Kerberos is in use: 

• The virtual URL hostname must be part of the Kerberos 
realm (this is using the term realm in the Kerberos sense, not 
the ProxySG sense). 

• For a forward proxy, this hostname should be added to the 
DNS server for the same domain as the Kerberos protected 
resources so that requests for this address go directly to the 
ProxySG. 

In both NTLM and Kerberos, if single-signon is desired, then 
the virtual URL hostname must have no dots and must not be 
proxied by the browser. The client must be able to resolve this 
hostname to an IP address of the proxy. 

See Chapter 8: "Security and Authentication" on page 309 for 
more details on virtual URLs. 
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Creating the CPL 

You can create CPL policies now that you have completed IWA realm configuration. Be aware that the 
examples below are just part of a comprehensive authentication policy. By themselves, they are not 
adequate for your purposes. 

The examples below assume the default policy condition is allow. On new SGOS 4.x systems, the 
default policy condition is deny. 



Note: Refer to the Blue Coat ProxySG Content Policy Language Guide for details about CPL and 

how transactions trigger the evaluation of policy file layers. 



□ Every IWA-authenticated user is allowed access the ProxySG. 

< Proxy > 

authenticate (IWARealm) 

□ Group membership is the determining factor in granting access to the ProxySG. 

< Proxy > 

authenticate (IWARealm) 

< Proxy > 

group="Domain\internetusers" ALLOW 
deny 

Notes 

□ Forms authentication modes cannot be used with an IWA realm that allows only NTLM/Kerberos 
credentials. If a form mode is in use and the authentication realm is an IWA realm, you receive a 
configuration error. 

□ For Windows Internet Explorer IWA users who want true single-sign-on (allowing Internet 
Explorer to provide your credentials automatically when challenged), you must set the virtual 
URL to a hostname that is resolvable to the IP address of the ProxySG by the client machines. Dots 
(for example, 1 0 . 1 . l . l) are not allowed. 



Note: Firefox (1.02 and higher) allows NTLM credentials for single sign-on but not Kerberos. 



To define the information in Internet Explorer, navigate to Internet Options>Security>Local 
intranet>Sites>Advanced...>Web sites. (For XP, navigate to Internet Options>Security>lnternet>Custom 
Level, then select Automatic logon with current username and password.) 

For Windows Internet Explorer 6.x, add the virtual host address to Internet Options>Privacy>Web 
Sites>Managed Web Sites>Always Allow 
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Section B: Windows Single Sign-on Authentication 

The Windows Single Sign-on (SSO) realm is an authentication mechanism available on Windows 
networks. 

This section discusses the following topics: 

□ "How Windows SSO Realms Work" 

□ "Creating a Windows SSO Realm" 

□ "Windows SSO Agents" 

□ "Configuring Authorization" 

□ "Defining Windows SSO Realm General Properties" 

□ "Creating the CPL" 

How Windows SSO Realms Work 

In a Windows SSO realm, the client is never challenged for authentication. Instead, the BCAAA agent 
collects information about the current logged on user from the domain controller and / or by querying 
the client machine. Then the IP address of an incoming client request is mapped to a user identity in 
the domain. If authorization information is also needed, then another realm (LDAP or local) must be 
created. For more information, see "How Windows SSO Authorization Works”. 



Note: The Windows SSO realm works reliably only in environments where one IP address maps 

to one user. If an IP address cannot be mapped to a single user, authentication fails. Those 
with NAT systems, which uses one set of IP addresses for intranet traffic and a different 
set for Internet traffic, should use a different realm for authentication. 



To authenticate a user, the Windows SSO realm uses two methods, either separately or together: 

□ Domain Controller Querying: The domain controller is queried to identify which users are 
connecting to, or authenticating with, the domain controller. This can be used to infer the identity 
of the user at a particular workstation. 

□ Client Querying: The client workstation is queried to determine who the client workstation thinks 
is logged in. 

□ When Domain Controller Querying and Client Querying are both used, the Domain Controller 
Query result is used if it exists and is still within the valid time-to-live as configured in the 

sso . ini file. If the Domain Controller Query result is older than the configured time-to-live, the 
client workstation is queried. 



Note: Before Domain Controller Querying or Client Querying can be used, the sso . ini file, 

located in the same directory as the BCAAA service, must be modified. For information 
on modifying this file, see "Modifying the sso. ini File for Windows SSO Realms". 
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For the most complete solution, an IWA realm could be configured at the same time as the Windows 
SSO realm and both realms added to a realm sequence. Then, if the Windows SSO realm failed to 
authenticate the user, the IWA realm could be used. For information on using a sequence realm, see 
"Sequence Realm Authentication". 

How Windows SSO Works with BCAAA 

The server side of the authentication exchange is handled by the Blue Coat Authentication and 
Authorization Agent (BCAAA). Windows SSO uses a single BCAAA process for all realms and 
proxies that use SSO. 



BCAAA must be installed on a domain controller or member server. By default, the BCAAA service 
authenticates users in all domains trusted by the computer on which it is running. When using 
Domain Controller Querying, the BCAAA service can be configured to only query certain domain 
controllers in those trusted domains. 

By default the BCAAA service is installed to run as LocalSystem. For a Windows SSO realm to have 
correct permissions to query domain controllers and clients, the user who BCAAA runs under must 
be an authenticated user of the domain. 

When the Windows SSO realm is configured to do Client Querying, the user that BCAAA runs under 
must be an authenticated user of the domain. For failover purposes, a second BCAAA can be installed 
and configured to act as an alternate BCAAA in the Windows SSO realm. The alternate BCAAA 
service is used in the event of a failure with the primary BCAAA service configured in the realm. 

BCAAA Synchronization 

Optionally, when using Domain Controller Querying, you can configure a BCAAA service to use 
another BCAAA service as a synchronization server. Whenever a BCAAA service restarts it will 
contact its synchronization server and update its logon state. Two given BCAAA services can use each 
other as their synchronization server. Thus, each BCAAA service can act as a synchronization server 
to provide logon state to other BCAAA services, as well as acting as a synchronization client to update 
its logon state from another BCAAA service. 

Each BCAAA service has a synchronization priority that determines synchronization behavior. If the 
client BCAAA has the same or higher priority than the server BCAAA, synchronization is done once 
at restart to update the client state. Once synchronization is complete the client BCAAA drops the 
synchronization connection and begins querying the domain controllers. 

Flowever, if the server BCAAA has higher priority, then the client BCAAA keeps the synchronization 
link open and continuously updates its logon state from the higher priority BCAAA. The client 
BCAAA does not query the domain controllers itself unless the synchronization link fails. 

This makes it possible to manage the query load on the domain controllers. If there is no issue with 
load, then the default configuration (without synchronization), with all BCAAA agents querying the 
domain controllers is acceptable. Flowever, if load on the domain controllers is an issue, 
synchronization can be used to minimize this load while still providing fail-over capabilities. 
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By default, all BCAAA agents have the same synchronization priority, meaning that they synchronize 
on startup and then do their own domain controller querying. To change the synchronization settings, 
see "To Configure the sso.ini file for Synchronization:” on page 358. 



Note: For information on configuring the BCAAA service as an authenticated user of the 

domain, see Appendix A: "Using the Authentication/ Authorization Agent". 



How Windows SSO Authorization Works 

The Windows SSO realm, in addition to allowing you to create and manipulate realm properties, such 
as the query type and the number of seconds that credential cache entries from this realm are valid, 
also contains the authorization username and the name of the realm that will do authorization for the 
Windows SSO realm. The authorization username is a string containing policy substitutions that 
describes how to construct the username for authorization lookups. This can either be an LDAP 
FQDN when the authorization realm is an LDAP realm, or a simple name when local realms are being 
used for authorization. 



Note: Windows SSO realms never challenge for credentials. If the authorization username 

cannot be determined from the configured substitutions, authorization in the Windows 
SSO realm fails. 



Keep in mind that Windows SSO realms do not require an authorization realm. If no authorization 
realm is configured, the user is not considered a member of any group. The effect this has on the user 
depends on the authorization policy. If the policy does not make any decisions based on groups, you 
do not need to specify an authorization realm. Also, if your policy is such that it works as desired 
when all Windows SSO realm users are not in any group, you do not have to specify an authorization 
realm. 

Creating a Windows SSO Realm 

The Configuration>Authentication>Windows SSO>Windows SSO Realms tab allows you to create a new 
Windows SSO realm. 

To Create a Windows SSO Realm through the Management Console 

1. Select Configuration>Authentication>Windows SSO>Windows SSO Realms. 

2. Click New. 
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Figure 9-5: Add Windows SSO Dialog 

3. In the Realm name field, enter a realm name. The name can be 32 characters long and composed of 
alphanumeric characters and underscores. The name must start with a letter. 

4. Click OK; click Apply. 



Windows SSO Agents 

You must configure the Windows realm so that it can find the Blue Coat Authentication and 
Authorization Agent (BCAAA). 

1. Select Configuration>Authentication>Windows SSO>Agents. 



Windows SSO Realms Agents j Authorization | Windows SSO General | 
Realm name: 



r Primary agent 



Host: 10.9.17.134 



Port; 16101 



- Alternate agent 
Host: 



Port: 16101 



r SSL Options 



0 Enable SSL 



0 Verify server certificate 



Timeout request after 60 



seconds 



Figure 9-6: Windows SSO Agents Tab 
2. Select the realm name to edit from the drop-down list. 



Note: You must have defined at least one Windows SSO realm (using the Windows SSO Realms 

tab) before attempting to configure the BCAAA agent. If the message Realms must be 
added in the Windows SSO Realms tab before editing this tab is displayed in red at the bottom 
of this page, you do not currently have any Windows SSO realms defined. 



3. In the Primary agent section, enter the hostname or IP address where the BCAAA agent resides. 

4. Change the port from the default of 16101 if necessary. 
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5. (Optional) Enter an alternate agent host and agent name in the Alternate agent section. 

The primary and alternate BCAAA server must work together to support fail-over. If the primary 
BCAAA server fails, the alternate server should be able to provide the same mappings for the IP 
addresses. 

6. (Optional) Click Enable SSL to enable SSL between the ProxySG and the BCAAA. 

7. (Optional) By default, if SSL is enabled, the Windows SSO BCAAA certificate is verified. To not 
verify the agent certificate, disable this setting. 

8. In the Timeout Request field, type the number of seconds the ProxySG allows for each request 
attempt before timing out. (The default request timeout is 60 seconds.) 

To Create and Define a Windows SSO Realm through the CLI 

1. At the (config) prompt, enter the following command to create a Windows SSO realm: 

SGOS# (config) security windows-sso create-realm realm_name 

where realm_name is the name of the Windows SSO realm. 

2. To redefine the Windows SSO realm configuration for the realm you just created, enter the 
following commands: 

SGOS# (config) security windows-sso edit-realm realm_name 

SGOS# (config windows-sso realm_name) primary-agent (host hostname / port 
port_number} 

and optionally, 

SGOS# (config windows-sso realm_name) alternate-agent (host hostname / port 
port_number} 



where: 



hostname 


The host where the primary or alternate BCAAA agent resides 


port number 


The port on the system where the primary or alternate BCAAA 
agent resides. The default port number is 16101. 



3. To enable SSL for this realm and to have the BCAAA certificate verified, enter: 

SGOS# (config windows-sso realm_name ) ssl enable 

SGOS# (config windows-sso realm_name ) ssl-verify-agent enable 

Configuring Authorization 

After the Windows SSO realm is created, you can use the Windows SSO Authorization tab to 
configure authorization for the realm. 



Note: Windows SSO realms do not require an authorization realm. If the policy does not make 

any decisions based on groups, you do not need to specify an authorization realm. 



1. Select Configuration>Authentication>Windows SSO>Authorization. 
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Windows SSO Realms | Agents Authorization | Windows SSO General j 
Realm name: | WSS01 ~ v 

Authorization realm name: | Local 1 v 

Authorization username: admin 

Figure 9-7: Windows SSO Authorization Tab 

2. From the Realm name drop-down list, select the Windows SSO realm for which you want to 
change realm properties. 



Note: You must have defined at least one Windows SSO realm (using the Windows SSO Realms 

tab) before attempting to set Windows SSO realm properties. If the message Realms must 
be added in the Windows SSO Realms tab before editing this tab is displayed in red at the 
bottom of this page, you do not currently have any Windows SSO realms defined. 



3. (Optional) From the Authorization realm name drop-down list, select the realm you want to use to 
authorize users. 

4. To construct usernames, keep in mind that the authorization username attributes is a string, that 
contains policy substitutions. When authorization is required for the transaction, the character 
string is processed by the policy substitution mechanism, using the current transaction as input. 
The resulting string becomes the user's authorization name for the current transaction. 



Table 9.9: Common Substitutions Used in the Authorization username Field 



ELFF Substitution 


CPL Equivalent 


Description 


x - c s - auth - domain 


$ (user . domain) 


The Windows domain of the authenticated user. 


cs -username 


$ (user .name) 


The relative username of the authenticated user. 



5. Click Apply. 



To Configure Authorization Settings through the CLI 

1 . At the (config) command prompt, enter the following commands to configure authorization 
settings: 

SGOS# (config windows-sso realm_name) authorization realm-name 
authorization-realm-name 

SGOS# (config windows-sso realm-name) authorization username 
author izat ion- username 

where: 
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authorization 

realm-name 


authorization- 

realm-name 


Specifies the realm to use to authorize the Windows SSO 
authenticated user. 


authorization 

username 


author i z at ion - 
username 


Specifies the character string containing policy 
substitutions that is to be used to construct the Windows 
SSO authenticated user's authorization username. 



Defining Windows SSO Realm General Properties 

The Windows SSO General tab allows you to specify the display name, the credential cache duration, 
and the type of authentication querying you want to do. After you select the type of authentication 
querying, you must modify the sso . ini file to enable the authentication querying. For information 
on modifying the sso . ini file, see "Modifying the sso. ini File for Windows SSO Realms" on 
page 357. 



Note: Windows SSO realms default to the origin-ip authentication mode when either no 

authentication mode or the auto authentication mode is specified in policy. After a user 
has first successfully authenticated to the ProxySG, all subsequent requests from that 
same IP address for the length of the cache duration are authenticated as that user. If the 
first user is allowed or denied access, subsequent users during that same time coming 
from the same IP address are allowed or denied as that first user. This is true even if 
policy would have treated them differently if they were authenticated as themselves. 

If multiple users often log in from the same IP address, a shorter cache duration timeout 
than the default or else an authentication mode that uses cookie surrogates are 
recommended . 



To Configure General Settings through the Management Console 
1. Select Configuration>Authentication>Windows SSO>Windows SSO General. 



Windows SSO Realms | Agents | Authorization Windows SSO General 



Realm name: 




WSS01 


V 


Cache credentials 


900 seconds 




Query type: 


Query Domain Controller and Client 


V 



Figure 9-8: Windows SSO General Tab 

2. From the Realm Name drop-down list, select the Windows SSO realm for which you want to 
change properties. 
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Note: You must have defined at least one Windows SSO realm (using the Windows SSO Realms 

tab) before attempting to set Windows SSO general properties. If the message Realms must 
be added in the Windows SSO Realms tab before editing this tab is displayed in red at the 
bottom of this page, you do not currently have any Windows SSO realms defined. 



3. Specify the length of time, in seconds, that user and administrator credentials received from the 
Windows SSO BCAAA service are cached. Credentials can be cached for up to 3932100 seconds. 
The default cache duration is 900 seconds (15 minutes). 



Note: If you specify 0, traffic is increased to the Windows SSO BCAAA service and the 

authorization server (if configured) because each authentication request generates an 
authentication request to the BCAAA service and an authorization request to the 
authorization server. 



4. In the Query Type field, select the method you want to use from the drop-down menu. 

By default the Windows SSO realm is configured for Domain Controller Querying only. 

If all of the client computers can be queried directly, then the most accurate results can be 
provided by the Query Clients option. 



Note: Client Querying is blocked by the Windows XP SP2 firewall. This can be overridden 

through domain policy. If the firewall setting "Allow remote administration exception" or 
"Allow file and printer sharing exception" or "Define port exceptions" (with port 445) is 
enabled, then the query will work. 



If an authentication mode without surrogates is being used (Proxy or Origin authenticate mode), 
then the Query Domain Controller and Client and Query Client options can cause too much traffic when 
querying the clients, as each authentication request results in a request to the BCAAA service, 
which can result in a client workstation query depending on the client query time-to-live. If the 
client workstation querying traffic is a concern, the Query Domain Controllers option should be used 
instead. 

5. Click Apply. 

To Configure General Settings through the CLI 

At the (conf ig) command prompt, enter the following commands to configure general settings: 

SGOS# (config windows-sso realm_name) cache-duration seconds 

SGOS# (config windows-sso realm_name) sso-type (query-client | query-dc ] 

query- dc- client} 
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where: 



cache -duration 


seconds 


Specifies the length of time in seconds that user and 
administrator credentials received from the Windows 
SSO BCAAA agent are cached. Credentials can be 
cached for up to 3932100 seconds. The default value is 
900 seconds (15 minutes). 


sso-type 


query-client | 
query- dc | 
query- dc- client 


Specifies whether you want to query the client, the 
domain controller, or both for authentication 
information. 



Modifying the sso.ini File for Windows SSO Realms 

To enable the method of authentication querying you choose, you must modify the sso . ini file by 
adding domain controllers you want to query and user accounts you want to ignore. 

The sso . ini file is located in the BCAAA installation directory. 

If you are only using one method of querying, you only need configure the specific settings for that 
method. If you plan to use both methods to query, you must configure all the settings. 



Note: The changes to the sso . ini file have no effect until the BCAAA service is restarted. 



To configure the sso.ini file for Domain Controller Querying 

1 . Open the file in a text editor. 

2. In the section DCQSetup, uncomment the line: DCQEnabled=l. 

3. In the section DCQDomainControllers, list the domain controllers you want to query or the IP 
address ranges of interest. 

By default all domain controllers that are in the forest or are trusted are queried. In large 
organizations, domain controllers that are not of interest for the ProxySG installation might be 
queried. The sso . ini file can be used to list the domain controllers of interest or IP address 
ranges of interest. 

4. In the section SSOServiceUsers, list the domain names of users who can access the domain 
controller on behalf of the service and mask the identity of the logged-on user. 

Listing these users here forces the BCAAA service to ignore them for authentication purposes. 

5. Save the sso . ini file. 
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To Configure the sso.ini file for Client Querying 



Note: Before you use the Windows SSO realm, you must change the BCAAA service to run as a 

domain user, and, if using XP clients, update the domain policy to allow the client query 
to pass through the firewall. 

For information on installing and configuring the BCAAA service, see Appendix A: 
"Using the Authentication/ Authorization Agent". 



1 . Open the file in a text editor. 

2. Review the TTL times in the section ClientQuerySetup to be sure they are appropriate for your 
network environment. 

3. Update the section SSOServiceUsers to ignore domain users used for services. 

4. Save the sso.ini file. 

To Configure the sso.ini file for Synchronization: 

1 . Open the file in a text editor. 

2. Update the section SSOSyncSetup (the defaults are listed below). Note that explanations of each 
setting are provided in the sso.ini file. 

• ServerPriority=100 

• EnableSyncServer=l 

• SyncPortNumber=16102 

• UseSSL=0 

• VerifyCertificate=0 

• QueryDelta=10 

• RetrySyncTime=60 

3. Update the section SSOSyncServer with the IP address or hostname of the BCAAA service to use 
a synchronization server. 

4. In the section SSOSyncClients, list the IP addresses or hostnames of the BCAAA services that will 
use this BCAAA service as their synchronization service. 

5. Save the sso . ini file. 

Creating the CPL 

You can create CPL policies now that you have completed Windows SSO realm configuration. Be 
aware that the examples below are just part of a comprehensive authentication policy. By themselves, 
they are not adequate for your purposes. 

The examples below assume the default policy condition is allow. On new systems, the default policy 
condition is deny. 
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Note: Refer to the Blue Coat ProxySG Content Policy Language Guide for details about CPL and 

how transactions trigger the evaluation of policy file layers. 



□ Every Windows SSO-authenticated user is allowed access the ProxySG. 

< Proxy > 

authenticate (WSSORealm) 

□ Group membership is the determining factor in granting access to the ProxySG. 

< Proxy > 

authenticate (WSSORealm) 

< Proxy > 

group="cn=proxyusers , ou=groups, o=myco" ALLOW 
deny 

Notes 

□ The Windows SSO realm works reliably only in environments where one IP address maps to one 
user. 

□ This realm never uses a password. 

□ When doing domain controller querying, the Windows SSO realm can lose the logon if the 
NetBIOS computer name cannot by determined through a DNS query or a NetBIOS query. The 
DNS query can fail if the NetBIOS name is different than the DNS host name or if the computer is 
in a different DNS domain than the BCAAA computer and the BCAAA computer is not set up to 
impute different DNS domains. 

The NetBIOS query can fail because the NetBIOS broadcast does not reach the target computer. 
This can happen if the computer is behind a firewall that is not forwarding NetBIOS requests or if 
the computer is on a subnet that is not considered to be local to the BCAAA server. 

To prevent this issue, the BCAAA machine must be configured to be able to query the NetBIOS 
name of any computer of interest and get the correct IP address. 

One workaround is to use a WINS server. This works like a DNS server but handles NetBIOS 
lookups. 
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Section C: LDAP Realm Authentication and Authorization 

Many companies and organizations use the Lightweight Directory Access Protocol (LDAP) as the 
directory protocol of choice, enabling software to find an individual user without knowing where that 
user is located in the network topography. 

This section discusses the following topics: 

□ "Overview" 

□ "Creating an LDAP Realm" 

□ "LDAP Servers" 

□ "Defining LDAP Base Distinguished Names" 

□ "LDAP Search & Groups Tab (Authorization and Group Information)" 

□ "Customizing LDAP Objectclass Attribute Values" 

□ "Defining Sequence Realm General Properties" 

□ "Creating the CPL" 

Overview 

Blue Coat supports both LDAP v2 and LDAP v3, but recommends LDAP v3 because it uses Transport 
Layer Security (TLS) and SSL to provide a secure connection between the SG appliance and the LDAP 
server. 

An LDAP directory, either version 2 or version 3, consists of a simple tree hierarchy. An LDAP 
directory might span multiple LDAP servers. In LDAP v3, servers can return referrals to others 
servers back to the client, allowing the client to follow those referrals if desired. 

Directory services simplify administration; any additions or changes made once to the information in 
the directory are immediately available to all users and directory-enabled applications, devices, and 
SG appliances. 

The SG appliance supports the use of external LDAP database servers to authenticate and authorize 
users on a per-group or per-attribute basis. 

LDAP group-based authentication for the SG appliance can be configured to support any 
LDAP-compliant directory including: 

□ Microsoft Active Directory Server 

□ N ovell NDS / eDirectory Server 

□ Netscape /Sun iPlanet Directory Server 

□ Other 

The ProxySG also provides the ability to search for a single user in a single root of an LDAP directory 
information tree (DIT), and to search in multiple Base Distinguished Names (DNs). 

You can configure a LDAP realm to use SSL when communicating to the LDAP server. 
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Configuring LDAP involves the following steps: 

□ Creating a realm (up to 40) and configuring basic settings. 

□ Configuring an LDAP server 

□ Defining LDAP Base Distinguished Names 

□ Defining Authorization and Group information 

□ Configuring general LDAP realm settings 

□ Creating policy 

Creating an LDAP Realm 

To Create an LDAP Realm through the Management Console 
1. Select Configuration>Authentication>LDAP>LDAP Realms. 



LDAP Realms | LDAP Servers | LDAP DN | LDAP Search 8, < | > 




2. Click New; the Add LDAP Realm dialog displays. 



Add LDAP Realm 



Realm name: | 

- Realm Configuration 

Type of LDAP server: g^ er v 

Primary server host: Port: [ 389 

User attribute type: | cn 



Other realm configuration parameters have been set to default values. 

| OK | | Cancel | 

Figure 9-10: Add LDAP Realm 

3. In the Real name field, enter a realm name. The name can be 32 characters long and composed of 
alphanumeric characters and underscores. The name must start with a letter. 
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4. From the Type of LDAP server drop-down list, select the specific LDAP server. 

5. Specify the host and port for the primary LDAP server. The host must be entered. The default port 
number is 389. 

6. In the User attribute type field, specify the default user attribute type for the type of LDAP server. 



Microsoft Active Directory Server 


sAMAccountName= 


Novell NDS/ eDirectory Server/ Other 


cn= 


Netscape/iPlanet Directory Server 


uid= 



7. Click OK; click Apply. 

To Create an LDAP Realm through the CLI 

At the (conf ig) command prompt, enter the following command to create an LDAP realm: 

SGOS# (config) security ldap create-realm {ad | iplanet [ nds | other} realm_name 
t base_dn ] primary_host [primary port] 



where: 



ad | iplanet | nds 
| other 


The type of LDAP realm to create, ad specifies a Microsoft Active 
Directory realm; iplanet specifies a Netscape/Sun iPlanet realm; nds 
specifies a Novell NDS/eDirectory realm; other specifies a realm of any 
other type. 


realm name 


The name of the new LDAP realm. 


base dn 


The distinguished name (DN) used as the unique key for the LDAP group 
database; the distinguished name of the key entry and all entries below it 
in the directory tree. You can specify additional Base DNs after the realm 
has been created. For example: ou=insidesales , o=toolsdivision. 
A Base DN can be up to 128 characters long. (In Netscape/iPlanet 
Directory Server, Base DN is also known as the Root DN.) See Table 9.1 for 
sample DN entries. 

At least one base DN is required for authentication to succeed, although 
you can create a realm without a base DN. 


primary host 


The host for the primary LDAP server. 


primary port 


The port for the primary LDAP server. The default port is 389. 



LDAP Servers 

Once you have created an LDAP realm, you can use the LDAP Servers page to change the current 
default settings. 
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Note that the default values exist. You do not need to change these values if the default settings are 
acceptable. 
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1. Select Configuration>Authentication»LDAP>LDAP Servers. 

LDAP Realms LDAP Servers | LDAP DN | LDAP Search 8, Gto | , | » 

Realm name: v J 

Type of LDAP server: | p lhe , v 

LDAP Protocol Version: |3 v □ Follow referrals 

- Servers 

Primary server host | 10.9.59.243 | — 

Alternate server host | Port ] 389 

- SSL Options 

[~~1 Enable SSL 

Timeout request after 60 ~| seconds 

Figure 9-11: LDAP Servers Tab 

2. From the Realm Name drop-down list, select the LDAP realm for which you want to change server 
properties. 



Note: You must have defined at least one LDAP realm (using the LDAP Realms tab) before 

attempting to set LDAP server properties. If the message Realms must be added in 
the LDAP Realms tab before editing this tab is displayed in red at the bottom 
of this page, you do not currently have any LDAP realms defined. 

3. From the Type of LDAP server drop-down list, select the specific LDAP server. 

4. From the LDAP Protocol Version drop-down list, select v2 for LDAP v2 support. LDAP v3 is the 
default. 

If you use LDAP v3, you can select Follow referrals to allow the client to follow referrals to other 
servers. (This feature is not available with LDAP v2.) The default is Disabled. 

5. Specify the host and port for the primary LDAP server. The host must be entered. The default port 
number is 389. 

6. (Optional) Specify the host and port for the alternate LDAP server. The default port is 389. 

7. (Optional) Under SSL Options, select Enable SSL to enable SSL. You can only select this option if 
you are using LDAP v3. 

8. (Optional) By default, if SSL is enabled, the LDAP server certificate is verified. If you do not want 
to verify the server certificate, disable this setting. 

9. (Optional) Change the timeout request for the server from its default of 60 seconds. 

10. Click Apply. Repeat the above steps for additional LDAP realms, up to a total of 40. 

To Edit LDAP Server Properties through the CLI 

1. From the (config) prompt, enter the following commands to modify LDAP realm authentication 
properties: 
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SGOS# (config) 
SGOS# (config 

and, optionally: 

SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 



security ldap edit-realm realm_name 
ldap realm_name ) primary- server host [port] 



ldap realm_name) 
ldap realm_name ) 
ldap realm_name ) 
ldap realm_name ) 
ldap realm_name ) 
ldap realm_name ) 
ldap realm_name ) 
ldap realm_name) 
ldap realm_name) 
ldap realm_name ) 
ldap realm_name) 
ldap realm_name) 
ldap realm_name) 



alternate-server host [port] 
distinguished-name base-dn clear 
distinguished-name base-dn add base_DN 
protocol -version {2 | 3} 
referrals-follow {enable | disable} 
spoof -authentication {none | origin | proxy} 
ssl {disable | enable} 
ssl-verify-server {disable | enable} 
validate-authorized-user {disable | enable} 
default-group-name group_name 
no default-group-name 
exit 

timeout seconds 



where 



alternate- server 


host [port] 


The host for the secondary LDAP server. 
The port can also be added, if you need it 
to be other than the default (389). 


distinguished name 
base-dn 


clear | add base DN 


Clears the existing base DN or adds the 
specified base DN. The distinguished 
name (DN) used as the unique key for the 
LDAP group database; the distinguished 
name of the key entry and all entries 
below it in the directory tree. You can 
specify additional base DNs after the 
realm has been created. For example: 
ou=insidesales , 
o=toolsdivision. A base DN can be 
up to 128 characters long. (In 
Netscape / iPlanet Directory Server, Base 
DN is also known as the Root DN.) See 
Table 9.1 for sample DN entries. 

At least one base DN is required for 
authentication to succeed, although you 
can create a realm without a base DN. 


protocol -vers ion 


2 | 3 


The LDAP version you want to use. 
LDAP v3 is the default, allowing you to 
use the referrals-follow argument 
and to use SSL. 


referrals-follow 


enable | disable 


Allows the client to follow referrals to 
other servers. This argument is not 
available if you use LDAP v2. 
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spoof -authentication 


none | origin | 
proxy 


Enables/ disables the forwarding of 
authenticated credentials to the origin 
content server or for proxy 
authentication. You can only choose one. 

• If set to origin, the spoofed header is an 
Authorization: header. 

• If set to proxy, the spoofed header is a 
Proxy-Authorization: header. 

• If set to none, no spoofing occurs. 

Flush the entries for a realm if the 
spoof-authentication value is changed to 
ensure that the spoof-authentication 
value is immediately applied. 


ssl 


enable | disable 


Enables or disables SSL. This argument is 
not available if you use LDAP v2. 


s si -verify- server 


enable | disable 


By default, if SSL is enabled, the LDAP 
server certificate is verified. To not verify 
the server certificate, disable this setting. 
This command is not overridden by the 
CPL property 

server . certificate .validate or 
the forwarding hosts 
ssl-verify-server command. 


val idate- author ized- 
user 


enable | disable 


When validate-authorized-user is 
enabled, an authorization (not 
authentication) request will verify that 
the user exists in the LDAP server. If the 
user does not exist, the authorization 
request fails (authentication requests 
always require the user to exist). 

When validate-authorized-user is 
disabled, no user existence check is made 
for an authorization request. If the user 
does not exist, the authorization request 
succeeds. 


default- group - name 


group name 


If the validate-authorized-user 
command is disabled and a 
default-group-name is configured, the 
default-group-name is used as the group 
name for non-existent users. 


no default -group-name 




Clears the default group name. 


timeout 


seconds 


Changes the timeout request for the 
server from its default of 60 seconds. 



2. (Optional) View the configuration (results shown are truncated): 
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SGOS# (config ldap realm_name ) 
Realm name : 

Display name: 

Server type : 

Protocol version: 

Follow referrals: 

Case sensitivity: 

User attribute type: 

Base DNs : 

Primary server host : 

Primary server port : 



view 

ldap_l 

testee 

Other 

3 

disabled 

disabled 

cn 

ou= ins ides ales 

10.9.16.85 

389 



Defining LDAP Base Distinguished Names 

The ProxySG allows you to specify multiple Base Distinguished Names (DNs) to search per realm, 
along with the ability to specify a specific branch of a Base DN. 

A Base DN identifies the entry that is starting point of the search. You must specify at least one 
non-null base-DN for LDAP authentication to succeed. 



You must enter complete DNs. Table 9.1 lists some examples of distinguished name attributes. 
Table 9.1 : Distinguished Name Attributes 



DN Attribute Syntax 


Parameter Description 


c= country 


Country in which the user or group resides. Examples: c=US, c=GB. 


cn = common name 


Full name of person or object defined by the entry. Examples: 
cn=David Smith, cn=Administrators, cn=4th floor 
printer 


mail =e-mail address 


User or group e-mail address. 


givenName=gi ven name 


User's first name. 


l=locality 


Locality in which the user or group resides. This can be the name of a 
city, country, township, or other geographic regions. Examples: 
l = Seattle, l = Pacific Northwest, l=King County. 


o= organization 


Organization to which the user or group is a member. Examples: 
o=Blue Coat Inc, o=UW. 


ou=organizational unit 


Unit within an organization. Examples: ou=Sales, ou=IT, 
ou= Compliance. 


st=state or province 


State or province in which the user or group resides. Examples: 
st=Washington, st = Florida. 


user Pas sword =pas sword 


Password created by a user. 


streetAddress=street address 


Street number and address of user or group defined by the entry. 
Example: streetAddress= 650 Almanor Avenue Sunnyvale, 
California 94085-3515. 
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Table 9.1 : Distinguished Name Attributes (Continued) 



DN Attribute Syntax 


Parameter Description 


sn =surname 


User's last name. 


telephoneNumber= telephone 


User or group telephone number. 


title=title 


User's job title. 


uid=user ID 


Name that uniquely identifies the person or object defined by the 
entry. Examples: uid=ssmith, uid=kjones. 



To Define Searchable LDAP Base DNs through the Management Console 

1. Select Configuration>Authentication>LDAP>LDAP DN. 

LDAP Realms | LDAP Servers LDAP DN ] LDAP Search t, Gtoj < | > 

Realm name: Idapl v | 

- Distinguished name 

User attribute type: | C n 

r Base DNs 




New ] Edit | Delete 

List order indicates preference | Promote entry 

I Demote entry ] 

Figure 9-12: LDAP DN Tab 

2. From the Realm Name drop-down list, select the LDAP realm for which you want to change DN 
properties. 



Note: You must have defined at least one LDAP realm (using the LDAP Realms tab) before 

attempting to set LDAP server properties. If the message Realms must be added in the 
LDAP Realms tab before editing this tab is displayed in red at the bottom of this 
page, you do not currently have any LDAP realms defined. 



3. In the User attribute type field, the ProxySG has entered the default user attribute type for the type 
of LDAP server you specified when creating the realm. 



Microsoft Active Directory Server 


sAMAccountName= 


Novell NDS/eDirectory Server/ Other 


cn= 


Netscape/iPlanet Directory Server 


uid= 



If you entered information correctly when creating the realm, you do not need to change the User 
attribute type in this step. If you do need to change or edit the entry, do so directly in the field. 
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4. Enter as many Base DNs as you need for the realm. Assume, for example, that Sample_Company 
has offices in New York and Lisbon, each with its own Base DN. 

o=NewYork o=Lisbon 



ou=Sales oivMaiuifacturing ou=Sales ou=Maniifacturing 
Figure 9-13: Simplified Directory Information Trees 

To specify entries for the Base DNs field, click New, enter the Base DN, and click OK. Repeat for 
multiple Base DNs. To search all of Sample_Company, enter o values: 

Base DNs 

|o=Rome 

o=NewYork 

j New 1 1 Edil | Delete j 

List order indicates search order Promote | Demote | 

Figure 9-14: Searching Sample_Company 

To search the manufacturing organizations, rather than starting at the top, enter ou and o values: 

Base DNs 



ou=manufacturing, o=NewYork 



| ou=manufacturing, o=Rome 

New Edit Delete j 

List order indicates search order Promote | Demote | 

Figure 9-15: Searching Part of Sample_Company 

You can add, edit, and delete Base DNs for a ProxySG to search. You can also select an individual 
DN and move it up or down in the list with the Promote and Demote buttons. The ProxySG 
searches multiple DNs in the order listed, starting at the top and working down. 

5. Click Apply to save the changes. 

To Define One or More Searchable LDAP Base DNs through the CLI 

1. To define a Base DN, enter the following command: 

SGOS# (config ldap realm_name ) distinguished-name base-dn add base-dn 

where base-dn is a string up to 128 characters long in the format appropriate to the type 
of LDAP server represented by the realm name. The base-dn should be the 
Fully-Qualified Domain Name (FQDN) of the base of the search. 

Repeat this step for each additional Base DN you want added to the list. Entries in the list 
start with the first Base DN created; subsequent additions are appended to the list. The 
list is searched from the top down. 

2. (Optional) To remove a Base DN: 

SGOS# (config ldap realm_name) distinguished-name base-dn remove base_dn 

3. (Optional) To remove all Base DNs and clear the list: 
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SGOS# (config ldap realm_name ) distinguished-name base-dn clear 

4. (Optional) To move a Base DN up or down in the list of Base DNs: 

SGOS# (config ldap realm_name ) distinguished-name base-dn {promote | demote} 

base_dn 

where promote moves the specified Base DN up one level in the list and demote moves it 
down one level. You must issue the command for each level you want to move the Base 
DN. 

LDAP Search & Groups Tab (Authorization and Group Information) 

After creating an LDAP realm, providing at least the required fields of the LDAP server for that realm, 
and defining base DNs for the realm, you must define authorization properties for each LDAP realm 
you created. 



Note: Authorization decisions are completely handled by policy. The groups that the ProxySG 

looks up and queries are derived from the groups specified in policy in group= 
conditions, attribute= conditions, and has Attribute conditions. If you do not have any 
of those conditions, then Blue Coat does not look up any groups or attributes to make 
policy decisions based on authorization. 



To Define LDAP Realm Authorization Properties through the Management Console 

1. Select Configuration>Authentication>LDAP>LDAP Search & Groups. 

IAP Realms j LDAP Servers j LDAPDN LDAP Search & Groups < | > 

Realm name: Idapl v 

- Search 

pi Anonymous search allowed 

Search user DN: | | 

| Change Password | Change Ihe search user password 

Dereference aliases: always v 

- Group information 

Membership type: @ User O Group 

Membership attribute: member 

Username type to lookup: 0 FQDN Relative 

Figure 9-16: LDAP Search & Groups Tab 

2. From the Realm Name drop-down list, select the LDAP realm for which you want to specify 
authorization information. 



Note: You must have defined at least one LDAP realm (using the LDAP Realms tab) before 

attempting to set LDAP Search & Group properties. If the message Realms must be 
added in the LDAP Realms tab before editing this tab is displayed in red at the 
bottom of this page, you do not currently have any LDAP realms defined. 
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3. Specify whether to allow anonymous search or to enforce user authentication before allowing a 
search. 

Some directories require a valid user to be able to perform an LDAP search; they do not allow 
anonymous bind. (Active Directory is one such example.) For these directories, you must specify a 
valid fully-qualified distinguished username and the password that permits directory access 
privileges. (For example, cn=user1,cn=users,dc=bluecoat,dc=com is a possible fully-qualified 
distinguished name.) 

To permit users to anonymously bind to the LDAP service, select Anonymous Search Allowed. For 
example, with Netscape /iPlanet Directory Server, when anonymous access is allowed, no 
username or password is required by the LDAP client to retrieve information. 

The LDAP directory attributes available for an anonymous client are typically a subset of those 
available when a valid user distinguished name and password have been used as search 
credentials. 

To enforce user authentication before binding to the LDAP service, deselect Anonymous Search 
Allowed, and set the Search User DN and Search User Password. Enter a user distinguished name in 
the Search User DN field. This username can identify a single user or a user object that acts as a 
proxy for multiple users (a pool of administrators, for example). A search user distinguished 
name can be up to 512 characters long. 

You can set or change the user password by clicking Change Password. This password can be up to 
64 alphanumeric characters long. 

You can create a separate user (such as Blue Coat, for example) instead of using an Administrator 
distinguished name and password. 

The Dereference level field has four values — always, finding, never, searching — that allow you to 
specify when to search for a specific object rather than search for the object's alias. The default is 
Always. 

4. Group Information 

Membership type and Membership attribute: The ProxySG enters the appropriate default: 

• Microsoft Active Directory: 

Membership type: user 
Membership attribute type: memberOf 

• Netscape/Sun iPlanet: 

Membership type:group 

Membership attribute type:uniqueMember 

• Novell NDS eDirectory 
Membership type:group 
Membership attribute type:member 

• Other 

Membership type:user 
Membership attribute type:member 

Username type to lookup: Select either FQDN or Relative. Only one can be selected at a time. 
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• Relative can only be selected in the membership type is Group. 

• FQDN indicates that the lookup is done only on the user object. FQDN can be selected when the 
membership type is either Group or User. 

5. Click Apply. 

To Define LDAP Realm Authorization Properties through the CLI 

1. Define the search criteria for the LDAP realm: 

SGOS# (config ldap realm_name ) search {anonymous {disable | enable} | dereference 
{always | finding | never | searching} | password password | encrypted-password 

encrypted_password | user-dn user_dn } 



where: 



anonymous 


disable | 
enable 


If disabled, users are not permitted to anonymously bind to the 
LDAP service. 

If enabled, users are permitted to anonymously bind to the 
LDAP service. When anonymous access is allowed, no 
password is required by the LDAP client to retrieve information, 
however, one can be specified, if extra security is desirable. 

The LDAP directory attributes available for an anonymous 
client are typically a subset of those available to clients that have 
been authenticated through a user distinguished name and 
password. 


dereference 


always | 
finding | 
never | 
searching 


Sets dereference options. 

always dereference aliases is the default. 

finding dereferences aliases only during name resolution. 

searching dereferences aliases only after name resolution. 

never means that aliases are never dereferenced. 


password | 
encrypted- 
password 


password \ 

encrypted 

password 


Specifies the user password (or encrypted password) associated 
with the user distinguished name. The non-encrypted (or 
plain-text) password can be up to 64 alphanumeric characters 
long. 

The primary use of the encrypted-password command is to 
allow the ProxySG to reload a password that it encrypted. You 
can choose to use a third-party encryption application. The 
encrypted password is encrypted using RSA with OAEP 
padding, and is Base64 encoded with no newlines. 


user-dn 


user_dn 


Specifies a user distinguished name. This username can identify 
a single user or a user object that acts as a proxy for multiple 
users (a pool of administrators, for example). Search user 
distinguished name can be up to 512 characters long. 



2. To define LDAP realm membership properties: 

SGOS# (config ldap realm_name ) membership-attribute membership_attribute 
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where membership_attribute is the name of the attribute that has the group information. 
(For Active Directory, the attribute name is memberOf . For iPlanet, the attribute name is 
uniquemember. For Novell Directory service, the attribute name is member.) 

SGOS# (config ldap realm_name ) membership- type {group | user} 

where group specifies that this realm is composed of individual members belonging to a 
group defined elsewhere, and user specifies that this realm is composed of individual 
disparate members whose only link to each other is membership in this group. 

SGOS# (config ldap realm_name ) membership-username (full | relative) 

where full specifies that the user's FQDN is used during membership lookups, and 
relative specifies that the user's relative username is used during membership lookups. 
Only one can be selected at a time. 



Customizing LDAP Objectclass Attribute Values 

The objectclass attributes on an LDAP object define the type of object an entry is. For example, a user 
entry might have an objectclass attribute value of person while a group entry might have an 
objectclass attribute value of group. 

The objectclass attribute values defined on a particular entry can differ among LDAP servers. The 
objectclass attribute values are attribute values only, they are not DNs of any kind. 

Currently, the ob j ectclass attribute values are used by Blue Coat during a VPM browse of an LDAP 
server. If an administrator wants to browse the groups in a particular realm, the ProxySG searches the 
LDAP server for objects that have obj ectclass attribute values matching those in the group list and 
in the container list. The list of obj ectclass attribute values in the container list is needed so that 
containers that contain groups can be fetched and expanded correctly. 

To Customize LDAP Objectclass Attribute Values through the Management Console 
1. Select Configuration>Authentication>LDAP>LDAP Objectclasses. 



LDAP Search & Groups LDAP Objectclasses 



LDAP General | < | ► 



Realm name: Idapl v 

- Objectclass Values 

Object type: container v | 

r Objectclasses 



Objectclasses 




organizationalUnit 


A 


organization 


V 


locality 


country 


domain 


domainDNS 



New ~~| | Edit | [ Delete 



Figure 9-17: LDAP Objectclasses Tab 
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2. From the Realm name drop-down list, select the LDAP realm whose objectclasses you want to 
modify. 

3. From the Object type drop-down list, select the type of object: container, group, or user. 

4. To create or edit an object for the specified objectclass, click New or Edit. (The only difference is 
whether you are adding or editing an objectclass value.) 

The Add/Edit Objectclass Value dialog displays. 




Figure 9-18: Add Objectclass Value 

5. Enter or edit the objectclass, and click OK; click Apply. For example, objectclass=organization. 

To Customize LDAP Objectclass Attribute Values through the CLI 

At the (conf ig) prompt, enter the following command to configure general settings: 

SGOS# (config ldap realm_name) objectclass container {add container_obj ectclass \ 
clear | remove container_obj ectclass] 

SGOS# (config ldap realm_name) objectclass group {add group_obj ectclass | clear | 
remove group_obj ectclass] 

SGOS# (config ldap realm_name) objectclass user {add user_obj ectclass | clear | 
remove user_obj ectclass) 



where: 



container 


{ add | remove } 
container objectclass \ 
clear 


Adds/removes container objectclass values from 
the list (these values are used during VPM 
searches of the LDAP realm), or clears all values 
from the container objectclass list. 


group 


{ add | remove } 
group_obj ectclass \ 
clear 


Adds /removes group objectclass values from 
the list (these values are used during VPM 
searches of the LDAP realm), or clears all values 
from the group objectclass list. 


user 


{ add | remove } 
user_obj ectclass | clear 


Adds/removes user objectclass values from the 
list (these values are used during VPM searches 
of the LDAP realm), or clears all values from the 
user objectclass list. 
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Defining LDAP General Realm Properties 

The LDAP General page allows you to indicate whether an LDAP server is configured to expect 
case-sensitive usernames and passwords, the length of time that credentials are cached, the display 
name, and if you want to use a special virtual host for this realm. 

To Configure General LDAP Settings through the Management Console 

1. Select Configuration>Authentication>LDAP>LDAP General. 

LDAP Search & Groups | LDAP Objectdasses LDAP General j | ► 

Realm name: u„ n i v 



Display name: Idapl 

I | Case sensitive 

Cache credentials 900 1 seconds 

r Virtual URL 

URL: | | 

Figure 9-19: LDAP General Tab 

2. From the Realm Name drop-down list, select the LDAP realm for which you want to change 
properties. 



Note: You must have defined at least one LDAP realm (using the LDAP Realms tab) before 

attempting to set LDAP general properties. If the message Realms must be added in 
the LDAP Realms tab before editing this tab is displayed in red at the bottom of 
this page, you do not currently have any LDAP realms defined. 



3. If needed, give the LDAP realm a display name. The default value for the display name is the 
realm name. The display name cannot be longer than 128 characters and it cannot be null. 

4. If the LDAP server is configured to expect case-sensitive usernames and passwords, select Case 
sensitive. 

5. Specify the length of time in seconds that user and administrator credentials received from the 
LDAP server are cached. Credentials can be cached for up to 3932100 seconds. The default value is 
900 seconds (15 minutes). 



Note: If you specify 0, this increases traffic to the LDAP server because each authentication 

request generates an authentication and authorization request to the server. 



6. You can specify a virtual URL based on the individual realm. For information on the virtual URL, 
see "Understanding Origin-Style Redirection" on page 326. 
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To Configure General LDAP Settings through the CLI 



At the (conf ig) prompt, enter the following command to configure general settings: 



SGOS# 


(conf ig 


ldap 


realm 


name 


SGOS# 


(conf ig 


ldap 


realm 


name 


SGOS# 


(conf ig 


ldap 


realm 


name 


SGOS# 


(conf ig 


ldap 


realm 


name 


SGOS# 


(conf ig 


ldap 


realm 


name 


where: 









cache-duration seconds 
case-sensitive {enable | disable} 
virtual -url URL 
display -name display_name 
rename new realm name 



cache -duration 


seconds 


Specifies the length of time in seconds that user and 
administrator credentials received from the LDAP server are 
cached. Credentials can be cached for up to 3932100 seconds. 
The default value is 90 0 seconds (15 minutes). 

If you specify 0, cached user and administrator credentials are 
not re-used. 


case-sensitive 


enable | 
disable 


Enable this setting if the LDAP server is configured to expect 
case-sensitive usernames and passwords. 


virtual-url 


URL 


The URL to redirect to when the user needs to be challenged 
for credentials. See Chapter 8: "Security and Authentication" 
on page 309. 


display-name 


display_ 

name 


The default value for the display name is the realm name. The 
display name cannot be longer than 128 characters and cannot 
be null. 


rename 


new realm 
name 


Allows you to change the realm name of an existing realm. 



Creating the CPL 

Be aware that the examples below are just part of a comprehensive authentication policy. By 
themselves, they are not adequate for your purposes. 



Note: Refer to the Blue Coat ProxySG Content Policy Language Guide for details about CPL and 

how transactions trigger the evaluation of policy file layers. 



Be aware that the default policy condition for these examples is allow. The default policy condition on 
new SGOS 4.x systems is deny. 

□ Every LDAP-authenticated user is allowed access the ProxySG. 

< Proxy > 

authenticate (LDAPRealm) 

□ Group membership is the determining factor in granting access to the ProxySG. 
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< Proxy > 

authenticate (LDAPRealm) 

< Proxy > 

group="cn=proxyusers , ou=groups, o=myco" 
deny 

□ A subnet definition determines the members of a group, in this case, members of the Human 
Resources department. 

< Proxy > 

authenticate (LDAPRealm) 

< Proxy > 

Define subnet HRSubnet 

192 . 168 . 0 . 0/16 

10 . 0 . 0 . 0/24 

End subnet HRSubnet 
[Rule] client_address=HRSubnet 
url . domain=monster . com 
url . domain=hot j obs . com 
deny 



[Rule] 

deny 
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Section D: Novell Single Sign-on Authentication and Authorization 



The Novell® Single Sign-on (SSO) realm is an authentication mechanism that provides single sign-on 
authentication for users that authenticate against a Novell eDirectory server. The mechanism uses the 
Novell eDirectory Network Address attribute to map the user's IP address to an LDAP FQDN. Since 
the mechanism is based on the user's IP address, it only works in environments where an IP address 
can be mapped to a unique user. 

A Novell SSO realm consists of 

□ BCAAA service information 

□ Novell eDirectory information 

□ authorization realm information 

□ general realm information. 

The Novell eDirectory information consists of a ProxySG LDAP realm that points to the master Novell 
eDirectory server that it is to be searched and monitored for user logins (see "Section C: LDAP Realm 
Authentication and Authorization" on page 360 for information on configuring LDAP realms) and a 
list of eDirectory server and port combinations that specify additional servers to monitor for logins. 
Additional monitor servers must be specified if they contain user information that is not replicated to 
the master Novell eDirectory server being searched. 

After a Novell SSO realm has been configured, you can write policy that authenticates and authorizes 
users against the Novell SSO realm. 

To ensure that users who do not successfully authenticate against the Novell SSO realm are not 
challenged, administrators can use a realm sequence that contains the Novell SSO realm and then a 
policy substitution realm to use when Novell SSO authentication fails. 



Note: The Novell SSO realm works reliably only in environments where one IP address maps to 

one user. If an IP address cannot be mapped to a single user, authentication fails. Those 
with NAT systems, which uses one set of IP addresses for intranet traffic and a different 
set for Internet traffic, may need to use a different realm for authentication. 



This section discusses the following topics: 

□ "How Novell SSO Realms Work" on page 378 

□ "Creating a Novell SSO Realm" on page 379 

□ "Novell SSO Agents" on page 379 

□ "Adding LDAP Servers to Search and Monitor" on page 382 

□ "Querying the LDAP Search Realm" on page 383 

□ "Configuring Authorization" on page 385 

□ "Defining Novell SSO Realm General Properties” on page 386 
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□ "Modifying the sso.ini File for Novell SSO Realms" on page 387 

□ "Creating the CPL" on page 388 

□ "Notes" on page 388 

How Novell SSO Realms Work 

When a user logs into the Novell network, the user entry in Novell eDirectory is updated with the 
login time and the IP address that the user logged in from and the login time. The ProxySG uses 
BCAAA to do LDAP searches and monitoring of the configured Novell eDirectory servers to obtain 
the user login information and maintain a user IP address to user FQDN map. 

To create the initial IP/FQDN map, the BCAAA service searches the configured master eDirectory 
server for all user objects within the configured base DNs that have a Network Address attribute. For 
each user entry returned, BCAAA parses the Network Address attribute and adds the IP/FQDN 
entry to the map. If an existing entry exists for that IP address, it is overwritten. 

A user entry can have more than one Network Address entry in which case an entry for each IP 
address is added to the map. Since service accounts can login using the same IP address and 
subsequently overwrite entries for actual users, the BCAAA service has a configurable list of the 
Service names to ignore. Users can be added or removed from the list in the sso.ini file, (see 
"Modifying the sso.ini File for Novell SSO Realms" on page 387.) 

Once the initial map has been created it is kept current by monitoring all of the eDirectory servers that 
contain unique partition data for the eDirectory tree. By default, the search server defined by the 
LDAP realm is monitored. If other servers contain data that is not replicated to the search server, they 
must be individually monitored. When a server is being monitored, each time a user logs in or logs 
out, an event message is sent to BCAAA to update its mapping of FQDNs to IP addresses. 

Multiple ProxySG devices can talk to the same BCAAA service and can reference the same eDirectory 
servers. To avoid multiple queries to the same server, the LDAP hostname and port combination 
uniquely identifies an eDirectory configuration and should be shared across devices. 

To ensure that BCAAA has complete map of FQDNs to IP addresses, the realm can be configured to 
do a full search of the configured master eDirectory server up to once per day. 

The BCAAA service must be version 120 or higher and must be installed on a Windows 2000+ 
machine that can access the eDirectory server. The BCAAA machine does not need to have a Windows 
trust relationship with the eDirectory server. 



Note: For information on configuring the BCAAA service, see Appendix A: "Using the 

Authentication/ Authorization Agent". 



How Novell SSO Authorization Works 

A Novell SSO realm can be configured to do no authorization, authorize against itself (the default), or 
authorize against another valid authorization realm. 
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When a Novell SSO realm is configured to authorize against itself, authorization is done through the 
LDAP search realm specified by the Novell SSO realm. The behavior is similar to the Novell SSO 
realm explicitly selecting the LDAP realm as the authorization realm. 

Creating a Novell SSO Realm 

The Configuration>Authentication>Novell SSO>Novell SSO Realms tab allows you to create a new Novell 
SSO realm. Up to 40 Novell SSO realms can be created. 

To Create a Novell SSO Realm through the Management Console 

1. Select Configuration>Authentication>Novell SSO>Novell SSO Realms. 

2. Click New. 




Figure 9-20: Add Novell SSO Dialog 

3. In the Realm name field, enter a realm name. The name can be 32 characters long and composed of 
alphanumeric characters and underscores. The name must start with a letter. 

4. Click OK; click Apply. 

Novell SSO Agents 

You must configure the Novell realm so that it can find the Blue Coat Authentication and 
Authorization Agent (BCAAA). 

1. Select Configuration>Authentication>Novell SSO>Agents. 
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Novell S50 Realms Agents | LDAP Servers j LDAP Queries j Authorization | Novell SSO Genet < | > 



Realm name: Novell.! 




- Alternate agent 

Host: 

[ Change Private Key Password ] 

- SSL Options 

|~1 Enable SSL Verify server certificate 

Timeout request after 60 seconds 

Figure 9-21 : Novell SSO Agents Tab 

2. Select the realm name to edit from the drop-down list. 

Note: You must have defined at least one Novell SSO realm (using the Novell SSO Realms tab) 

before attempting to configure the BCAAA agent. If the message Realms must be added in 
the Novell SSO Realms tab before editing this tab is displayed in red at the bottom of this 
page, you do not currently have any Novell SSO realms defined. 



3. In the Primary agent section, enter the hostname or IP address where the BCAAA agent resides. 

4. Change the port from the default of 16101 if necessary. 

5. (Optional) You can change the encrypted passwords for the private key and public certificate on 
the BCAAA machine that are to be used for SSL communication between the BCAAA service and 
the Novell eDirectory server by clicking Change Private Key Password or Change Public Certificate 
Password. The location of the private key and public certificate are specified in the sso . ini file 
on the BCAAA machine. (For information on changing the location of the private key and public 
certificate, see "Modifying the sso. ini File for Novell SSO Realms” on page 387.) 

6. (Optional) Enter an alternate agent host and agent name in the Alternate agent section. Note that 
you can also change the passwords for the private key and public certificate for the alternate 
agent, as well. 

The primary and alternate BCAAA server must work together to support fail-over. If the primary 
BCAAA server fails, the alternate server should be able to search and monitor the same set of 
eDirectory servers. 

7. (Optional) Click Enable SSL to enable SSL between the ProxySG and the BCAAA. 

8. (Optional) By default, if SSL is enabled, the BCAAA service's certificate is verified. To not verify 
the agent certificate, disable this setting. 



Port: [ 16101 | 

| Change Public Certificate Password | 
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Note: The Enable SSL setting only enables SSL between the ProxySG and BCAAA. To enable SSL 

between BCAAA and the eDirectory server, the Enable SSL setting must be set in the 
LDAP search realm. 



9. In the Timeout Request field, type the number of seconds the ProxySG allows for each request 
attempt before timing out. (The default request timeout is 60 seconds.) 

10. Click Apply to save the changes. 

To Create and Define a Novell SSO Realm through the CLI 

1. At the (config) prompt: 

SGOS# (config) security novell-sso create-realm realm_name 
where realm_name is the name of the Novell SSO realm. 

2. To define the Novell SSO realm configuration for the realm you just created, enter the following 
commands: 

SGOS# (config) security novell-sso edit-realm realm_name 

SGOS# (config novell-sso realm_name ) primary-agent {host host / port port / 

encrypted-private-key-password encrypted-private-key-password / 
encrypted-public- certificate -password encrypted-public- certificate -password / 
private-key-password private-key-password / public-certificate-password 

public- certifi cate -pas sword} 

and optionally, 

SGOS# (config novell-sso realm_name ) alternate-agent {host host / port port / 
encrypted-private-key-password encrypted-private-key-password / 
encrypted-public -certificate -pas sword encrypted-public -certificate -pas sword / 

private-key-password private-key-password / public-certificate-password 

public -certifi cate -pas sword} 



host 


host 


The host where the primary or alternate BCAAA 
service resides. 


port 


port 


The port on the system where the primary or 
alternate BCAAA service resides. The default port 
number is 16101 . 


private- 
key-pas sword 

or 

encrypted-private- 

key-password 


private-key- 

password 

or 

encrypted-private- 

key-password 


The password or encrypted password for the 
private key on the BCAAA machine that is to be 
used for SSL communication between the 
BCAAA service and the Novell eDirectory server. 
The location of the private key is specified in the 
sso . ini file on the BCAAA machine. 
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public -cert if icate- 
password 

or encrypted-public- 
certif icate -password 



public -certificate 
-password 

or 

encrypt ed-public- 

certificate- 

password 



The password or encrypted password for the 
public certificate on the BCAAA machine that is 
to be used for SSL communication between the 
BCAAA service and the Novell eDirectory server. 
The location of the public certificate is specified in 
the sso . ini file on the BCAAA machine. 



3. To enable SSL for this realm and to have the BCAAA certificate verified, enter: 

SG0S# (config novell-sso realm_name ) ssl enable 

SGOS# (config novell-sso realm_name ) ssl-verify-agent enable 

Adding LDAP Servers to Search and Monitor 

The BCAAA service searches and monitors specified eDirectory servers to determine which users are 
logged in and their Network Address attribute value. Those attribute values are converted into IP 
addresses, and BCAAA maintains a map of IP addresses to LDAP FQDNs. 

If the eDirectory tree is partitioned across multiple servers, the realm must monitor every eDirectory 
server that has unique user information. 

To Specific the eDirectory Servers: 

1. Select Configuration>Authentication>Novell SSO>LDAP Servers. 

LDAP Servers LDAP Queries J Authorization | Novell SSO General 

Realm name: Novell_l ' 

LDAP search realm name; [None > 

r Monitor servers 



Host 


Port 


1 10.9. 17. 134 


389 I 












New 


1 1 


Edit 


Delete 



Figure 9-22: Novell SSO LDAP Servers Tab 
2. Select the realm name to edit from the drop-down list. 
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Note: You must have defined at least one Novell SSO realm (using the Novell SSO Realms tab) 

before attempting to specify LDAP server configuration. If the message Realms must be 
added in the Novell SSO Realms tab before editing this tab is displayed in red at the bottom of 
this page, you do not currently have any Novell SSO realms defined. 



3. Select an LDAP realm from the drop-down list. The servers configured in this LDAP realm are 
used to do the full searches of the eDirectory tree. 

4. If you have a deployment with multiple servers holding partitions that are not fully replicated to 
the master server, you can monitor each LDAP server individually. To add an LDAP server to 
monitor, click New. 

5. Add the IP address and port of the LDAP server and click OK. 

6. Repeat for additional LDAP servers you need to monitor. 

7. Click Apply to save the changes. 

To specify the LDAP search realm and LDAP servers to monitor through the CLI: 

Enter the following commands: 

SGOS# (config) security novell-sso edit-realm realm_name 
SGOS#(config novell-sso realm_name ) ldap search-realm ldap_realm 
SGOS# (config novell-sso realm_name ) ldap monitor- servers (add host [port] 
clear | remove host [port] } 

where 



ldap search-realm 


ldap realm 


Specifies the LDAP search realm. 


ldap monitor-servers 


(add host [port] 
clear | remove host 
[port] } 


Allows you to add an LDAP server to 
monitor, to clear all LDAP servers on the 
monitor list, or to remove the specified 
LDAP server. 



Querying the LDAP Search Realm 

You can specify the time and days that a full search of the eDirectory tree is repeated in order to ensure 
that the mappings maintained by BCAAA are up to date. 

To specify search criteria through the Management Console: 

1. Select Configuration>Authentication>Novell SSO>LDAP Queries. 
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Novell SSO Reelms | Agents | LDAP Servers LDAP Queries | Authorization ; < 



Realm name: 



Novell_l 



v 



- Full search: 

Perform full search at: 



midnight 



v 



UTC on the following days: 



0 Sunday 0 Monday 0 Tuesday 

0 Wednesday 0 Thursday 0 Friday 0 Saturday 



Network Address LDAP name: | networkAddress 
Login Time LDAP name: [ loginTime 

Figure 9-23: The LDAP Queries Tab 

2. Select the realm name to edit from the drop-down list. 

Note: You must have defined at least one Novell SSO realm (using the Novell SSO Realms tab) 

before attempting to configure LDAP queries. If the message Realms must be added in the 
Novell SSO Realms tab before editing this tab is displayed in red at the bottom of this page, 
you do not currently have any Novell SSO realms defined. 



3. In the full search pane, specify the time of day you want the search to take place from the 
drop-down list. 

4. Select or de-select checkboxes to specify days to search. 

5. If you have changed the Novell eDirectory Network Address or Login Time LDAP attribute 
name, you can enter those changed names in the Network Address LDAP name and the Login Time 
LDAP name fields. The names must match the LDAP names configured on the eDirectory server 
for authentication to succeed. 

6. Click Apply. 

To specify search criteria through the CLI: 

Enter the following commands: 

SGOS# (config) security novell-sso edit-realm realm_name 

SGOS#(config novell-sso realm_name ) full-search day-of-week {all | friday | 
monday | no | none | Saturday | Sunday | thursday | tuesday | Wednesday} 

SGOS# (config novell-sso realm_name ) full-search time-of-day 0-23 
SGOS# (config novell-sso realm_name ) ldap-name {login-time ldap_name \ 

network-address ldap_name} 

where 
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day-of -week 


{all | friday | monday | no | none 
| Saturday | Sunday | thursday | 
tuesday | Wednesday} 


Specifies the days of the week to do 
full searches. No allows you to 
specify a day of the week to delete. 
None clears all days of the week. 
All specifies all days of the week. 


time -of -day 


0-23 


Specifies the UTC time of day, using 
a 24-hour clock, that you want the 
search to take place. 


ldap 


{login-time ldap name \ 
network-address ldap name } 


The Login Time and Network 
Address attributes can be changed to 
match the settings in your 
environment. 



Configuring Authorization 

Novell SSO realm can be configured to do no authorization, authorize against itself (the default), or 
authorize against another valid authorization realm (either LDAP or Local). 



To specify an authorization realm: 

1. Select Configuration>Authentication>Novell SSO>Authorization. 



Agents | LDAP Servers | LDAP Queries Authorization | Novell SSO General j | ► 



Realm name: 



Novell_l 



v 



Authorization realm name: 



0 Self 



Authorization username: ^ Use pqqn 

Figure 9-24: The Novell SSO Authorization Tab 

2. Select the realm name to edit from the drop-down list. 



Note: You must have defined at least one Novell SSO realm (using the Novell SSO Realms tab) 

before attempting to configure authorization. If the message Realms must be added in the 
Novell SSO Realms tab before editing this tab is displayed in red at the bottom of this page, 
you do not currently have any Novell SSO realms defined. 



3. The Novell SSO realm is selected to authorize against itself by default. To choose another realm, 
de-select the Self checkbox and choose an authorization realm from the drop-down list. 

4. The LDAP FQDN is selected as the Authorization user name, by default. You might want to change 
this if the user's authorization information resides in a different root DN. To choose a different 
authorization name, de-select the Use FQDN checkbox and enter a different name, for example: 

cn=$ (user . name ) , ou=partition, o=company 
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5. Click Apply. 



To Configure Authorization Settings through the CLI 

1 . At the (config) command prompt, enter the following commands to configure authorization 
settings: 

SGOS# (config novell-sso realm_name) authorization realm-name 
authorization -realm-name 

SGOS# (config novell-sso realm-name) authorization username 
authorization -username 

SGOS# (conf ig-novell-sso realm-name) authorization self {enable | disable} 
where: 



authorization 

realm-name 


authorization- 

realm-name 


Specifies the realm to use to authorize the Novell SSO 
authenticated user. 


authorization 

username 


author i z at ion - 
username 


Specifies the character string containing policy 
substitutions that is to be used to construct the Novell 
SSO authenticated user's authorization username. 


authorization 

self 


enable | disable 


Enables or disables the specified Novell SSO realm as the 
authorization realm. 


authorization 

no 


realm-name | 
username 


Clears the authorization realm or username. 



Defining Novell SSO Realm General Properties 

The Novell SSO General tab allows you to specify the credential cache duration. 



Note: Novell SSO realms default to the origin-ip authentication mode when either no 

authentication mode or the auto authentication mode is specified in policy. After a user 
has first successfully authenticated to the ProxySG, all subsequent requests from that 
same IP address for the length of the cache duration are authenticated as that user. If the 
first user is allowed or denied access, subsequent users during that same time coming 
from the same IP address are allowed or denied as that first user. This is true even if 
policy would have treated them differently if they were authenticated as themselves. 

If multiple users often log in from the same IP address, a shorter cache duration timeout 
than the default or else an authentication mode that does not use IP surrogates is 
recommended . 
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To Configure General Settings through the Management Console 

1. Select Configuration>Authentication>Novell SSO>Novell SSO General. 



Novell SSO Realms | Agents | LDAP Servers | LDAP Queries | Authorization { 4 1 t 



Realm name: 



Novell_l 



v 



Cache credentials j 900 seconds 

Figure 9-25: Novell SSO General Tab 

2. From the Realm Name drop-down list, select the Novell SSO realm for which you want to change 
properties. 



Note: You must have defined at least one Novell SSO realm (using the Novell SSO Realms tab) 

before attempting to set Novell SSO general properties. If the message Realms must be 
added in the Novell SSO Realms tab before editing this tab is displayed in red at the bottom of 
this page, you do not currently have any Novell SSO realms defined. 



3. Specify the length of time, in seconds, that user and administrator credentials received from the 
Novell SSO BCAAA service are cached. Credentials can be cached for up to 3932100 seconds. The 
default cache duration is 900 seconds (15 minutes). 

4. Click Apply. 

To Configure General Settings through the CLI 

At the (config) command prompt: 

SGOS# (config novell-sso realm_name ) cache-duration seconds 

where cache-duration specifies the length of time in seconds that user and administrator 
credentials received from the Novell SSO BCAAA agent are cached. Credentials can be cached for 
up to 3932100 seconds. The default value is 900 seconds (15 minutes). 



Modifying the sso.ini File for Novell SSO Realms 

The Novell SSO realm uses the sso . ini file for configuration parameters required by the BCAAA 
service to manage communication with the Novell eDirectory server. Three sections in the sso.ini file 
are related to the Novell SSO realm: NovellSetup, NovellTrustedRoot Certificates, and 
SSOServiceUsers. You only need to modify settings in the NovellTrustedRoot Certificates section if the 
LDAP realm used by the Novell SSO realm requires that the identity of the server be verified. 

The sso . ini file is located in the BCAAA installation directory. 



Note: The changes to the sso . ini file have no effect until the BCAAA service is restarted. 



To modify Novell SSO realms parameters: 

1 . Open the file in a text editor. 



387 



Blue Coat ProxySG Configuration and Management Guide 



Section D: Novell Single Sign-on Authentication and Authorization 

2. In the Novell Setup section, modify the parameters as needed (the default values are displayed 
below): 

• MonitorRetryTime=30 

• SearchRetryTime=30 

• TrustedRootCertificateEncoding=der 

• PublicCertificateEncoding=der 

• PrivateKeyFile= 

• PrivateKeyEncoding=der 

3. If the LDAP realm used by the Novell SSO realm requires that the identity of the server be 
verified, add the paths to the Trusted root certificate files in the NovellTrustedRootCertificates 
section. 

4. In the section SSOServiceUsers, list the names of users who can log in with eDirectory credentials 
on behalf of the service and mask the identity of the logged-on user. 

Listing these users here forces the BCAAA service to ignore them for authentication purposes. 

5. Save the sso . ini file. 

Creating the CPL 

You can create CPL policies now that you have completed Novell SSO realm configuration. Be aware 
that the examples below are just part of a comprehensive authentication policy. By themselves, they 
are not adequate for your purposes. 



Note: The examples below assume the default policy condition is allow. 



Refer to the Blue Coat ProxySG Content Policy Language Guide for details about CPL and how 
transactions trigger the evaluation of policy file layers. 

□ Every Novell SSO-authenticated user is allowed access the ProxySG. 

< Proxy > 

authenticate (NSSORealm) 

□ Group membership is the determining factor in granting access to the ProxySG. 

< Proxy > 

authenticate (NSSORealm) 

< Proxy > 

group="cn=proxyusers , ou=groups, o=myco" ALLOW 
deny 

Notes 

□ The Novell SSO realm works reliably only in environments where one IP address maps to one 
user. NAT environments are not supported. 
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□ Novell SSO realms are not supported in IPX environments. 

□ Event monitoring of eDirectory is only compatible with eDirectory 8 . 7 +. 

□ Upgrade to Novell client 4.91 SP1 or later if you experience issues with the Network Address 
attribute not being updated during login. 

□ Novell SSO realms do not use user credentials so they cannot spoof authentication information to 
an upstream server. 

□ If an upstream proxy is doing Novell SSO authentication, all downstream proxies must send the 
client IP address. 

□ There can be response time issues between the BCAAA service and the eDirectory servers during 
searches; configure the timeout for LDAP searches to allow the eDirectory server adequate time to 
reply. 
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Section E: RADIUS Realm Authentication and Authorization 

RADIUS is often the protocol of choice for ISPs or enterprises with very large numbers of users. 
RADIUS is designed to handle these large numbers through centralized user administration that eases 
the repetitive tasks of adding and deleting users and their authentication information. RADIUS also 
inherently provides some protection against sniffing. 

Some RADIUS servers support one-time passwords. One-time passwords are passwords that become 
invalid as soon as they are used. The passwords are often generated by a token or program, although 
pre-printed lists are also used. Using one-time passwords ensures that the password cannot be used in 
a replay attack. 

The SG appliance's one-time password support works with products such as Secure Computing 
Safe Word synchronous and asynchronous tokens and RSA SecurlD tokens. 

The SG appliance supports RADIUS servers that use challenge/ response as part of the authentication 
process. SafeWord asynchronous tokens use challenge/ response to provide authentication. SecurlD 
tokens use challenge/response to initialize or change PINs. 



Note: For this release, HTTP is the only supported protocol. 



The challenge is displayed as the realm information in the authentication dialog; Blue Coat 
recommends that you use form authentication if you create a challenge / response realm, particularly if 
you use SecurlD tokens. 

If you set an authentication mode that uses forms, the system detects what type of question is being 
asked. If it is a yes/ no question, it displays the query form with a yes and no button. If it is a new PIN 
question, the system displays a form with entry fields for the new PIN. 

For information on using form authentication, see "Forms-Based Authentication" on page 473. 

Using policy, you can fine-tune RADIUS realms based on RADIUS attributes. If you use the Blue Coat 
attribute, groups are supported within a RADIUS realm. 

This section discusses the following topics: 

□ "Creating a RADIUS Realm" 

□ "Defining RADIUS Realm Properties" 

□ "Defining RADIUS Realm General Properties" 

□ "Creating the Policy" 

□ "Troubleshooting" 

Creating a RADIUS Realm 

To Create a RADIUS Realm through the Management Console 

You can create up to 40 RADIUS realms. 
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1. Select Configuration>Authentication>RADIUS>RADIUS Realms. 

RADIUS Realms | RADIUS Servers | RADIUS General | 

r RADIUS Realms 




Figure 9-26: RADIUS Realms Tab 
2. Click New; the Add RADIUS Realm dialog displays. 




Figure 9-27: Add RADIUS Realm 

3. In the Realm name field, enter a realm name. The name can be 32 characters long and composed of 
alphanumeric characters and underscores. The name must start with a letter. 

4. Specify the host and port for the primary RADIUS server. The default port is 1 81 2. 

5. Specify the RADIUS secret. RADIUS secrets can be up to 64 characters long and are always case 
sensitive. 

6. Confirm the secret. 

7. Click OK; click Apply. 
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Defining RADIUS Realm Properties 

Once you have created the RADIUS realm, you can change the primary host, port, and secret of the 
RADIUS server for that realm. 

To Re-Define RADIUS Server Properties through the Management Console 

1. Select Configuration>Authentication>RADIUS>RADIUS Servers. 



RADIUS Realms 
Realm name: 
Primary Server 
Host:! 10.9.16.85 



RADIUS Servers 



RADIUS General 



( Change Secret 



Pott: 1812 



Alternate Server 
Host:! 



Change Secret 



Pott: | 1812 



Timeout request after 5 



|~~1 One-time passwords 



seconds; retry 5 



times 



Figure 9-28: RADIUS Servers Tab 



Note: You must have defined a RADIUS realm (using the RADIUS Realms tab) before 

attempting to set RADIUS server properties. If the message Realms must be added in 
the RADIUS Realms tab before editing this tab is displayed in red at the bottom of 
this page, you do not currently have a RADIUS realm defined. 



2. Specify the host and port for the primary RADIUS server. The default port is 1812. (To create or 
change the RADIUS secret, click Change Secret. RADIUS secrets can be up to 64 characters long 
and are always case sensitive.) 

3. (Optional) Specify the host and port for the alternate RADIUS server. The default port is 1812. (To 
create or change the RADIUS secret, click Change Secret. RADIUS secrets can be up to 64 
characters long and are always case sensitive.) 

4. In the Timeout Request field, enter the number of seconds the ProxySG allows for each request 
attempt before giving up on a server and trying another server. Within a timeout multiple packets 
can be sent to the server, in case the network is busy and packets are lost. The default request 
timeout is 10 seconds. 

5. In the Retry field, enter the number of attempts permitted before marking a server offline. The 
client maintains an average response time from the server; the retry interval is initially twice the 
average. If that retry packet fails, then the next packet waits twice as long again. This increases 
until it reaches the timeout value. The default number of retries is 1 0. 
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6. If you are using one-time passwords, select the One-time passwords checkbox. (For more 
information on using one-time passwords, see the RADIUS introduction on page 390.) You must 
enable one-time passwords if you created a challenge/response realm. 

7. Click Apply. 

Defining RADIUS Realm General Properties 

The RADIUS General tab allows you to specify the display name and a virtual URL. 

To Configure General Settings through the Management Console 

1. Select Configuration>Authentication>RADIUS>RADIUS General. 



RADIUS Realms | RADIUS Servers | RADIUS General | 




Note: You must have defined a RADIUS realm (using the RADIUS Realms tab) before 

attempting to set RADIUS server properties. If the message Realms must be added in 
the RADIUS Realms tab before editing this tab is displayed in red at the bottom of 
this page, you do not currently have a RADIUS realm defined. 



2. If needed, change the RADIUS realm display name. The default value for the display name is the 
realm name. The display name cannot be longer than 128 characters and it cannot be empty. 

3. If the RADIUS server is configured to expect case-sensitive usernames and passwords, make sure 
the Case sensitive checkbox is selected. 

4. Specify the length of time, in seconds, that user credentials received from the RADIUS server are 
cached. Credentials can be cached for up to 3932100 seconds. The default is 900 seconds (15 
minutes). 
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Note: If you specify 0, traffic is increased to the RADIUS server because each authentication 

request generates an authentication and authorization request. That is, if a Web page has 
15 images and is loaded, you must authenticate 16 times — once for the Web page and 
once for each image. 



5. (Optional) You can specify a virtual URL based on the individual realm. For more information on 
the virtual URL, see "Understanding Origin-Style Redirection" on page 326. 

6. Click Apply. 



To Create and Define a RADIUS Realm through the CLI 

1. At the (config) prompt, enter the following command to create a RADIUS realm: 

SGOS# (config) security radius create-realm realm_name secret primary- server_host 
[ pri mary- server_port ] 

-or- 

SGOS# (config) security radius create -realm- encrypted realm_name encrypted_secret 
primary_host [primary_por t] 

where: 



realm name 


The name of the RADIUS realm. 


secret / 

encrypted_secret 


The shared secret (or encrypted secret) associated with the primary RADIUS 
server. (RADIUS secrets can be up to 64 characters long and are always case 
sensitive.) 

The primary use of the encrypted-password command is to allow the 
ProxySG to reload a password that it encrypted. If you choose to use a 
third-party encryption application, be sure it supports RSA encryption, 
OAEP padding andBase64 encoded with no new lines. 


primary host 


The host for the primary RADIUS server. 


primary port 


The port for the primary RADIUS server. The default port is 1812 . 



2 . 



To set the newly-created RADIUS realm primary and alternate hosts and passwords, enter the 
following commands: 



SGOS# (config) security radius edit-realm realm_name 



SGOS# (config radius realm_name ) 
SGOS# (config radius realm_name) 



primary- server primary_host [primary_por t] 

primary- server secret secret 



SGOS# (config radius realm_name) primary- server encrypted-secret encrypted_secret 



and optionally: 
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SGOS# (config radius realm_name ) alternate-server alternate_host [ alternate_port ] 

SGOS#(config radius realm_name ) alternate-server secret secret 

-or- 

SGOS# (config radius realm_name ) alternate-server encrypted-secret 

encrypt ed_secret 
where : 



secret / 

encrypted secret 


The shared secret (or encrypted secret) associated with the primary or 
alternate RADIUS server. (RADIUS secrets can be up to 64 characters long and 
are always case sensitive.) 

Note that you must create the encrypted secret before executing the host 
[port] command. 

The primary use of the encrypted-password command is to allow the ProxySG 
to reload a password that it encrypted. You can choose to use a third-party 
encryption application. The encrypted password is encrypted using RSA with 
OAEP padding, and is Base64 encoded with no newlines. 


primary server 


The host for the primary RADIUS server. 


primary port 


The port for the primary RADIUS server. The default port is 1812 . 


alternate host 


The host for the alternate RADIUS server. 


alternate port 


The port for the alternate RADIUS server. The default port is 1812 . 



3. 



To complete configuration of the RADIUS realm, enter the following commands: 



SGOS# (config radius realm_name) 
SGOS# (config radius realm_name ) 
SGOS# (config radius realm_name ) 
SGOS# (config radius realm_name) 
SGOS# (config radius realm_name) 
SGOS# (config radius realm_name) 
SGOS# (config radius realm_name) 



timeout seconds 
server-retry count 
cache-duration seconds 
case-sensitive {enable | disable} 
display -name name 

spoof -authentication {none | origin | proxy} 
one- time-passwords {enable | disable} 



where: 



timeout 



seconds 



The number of seconds the ProxySG allows for 
each request attempt before giving up on a 
server and trying another server. Within a 
timeout multiple packets can be sent to the 
server, in case the network is busy and packets 
are lost. The default request timeout is 10 
seconds 
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server-retry 


count 


The number of attempts permitted before 
marking a server offline. The client maintains 
an average response time from the server; the 
retry interval is initially twice the average. If 
that retry packet fails, then the next packet 
waits twice as long again. This increases until 
it reaches the timeout value. The default 
number of retries is 1 0. 


cache -duration 


seconds 


The length of time that credentials should be 
cached for this RADIUS realm. The default is 9 0 0 
seconds (15 minutes) 


display-name 


name 


The default value for the display name is the realm 
name. The display name cannot be longer than 128 
characters and it cannot be empty. 


spoof -authentication 


none | 
origin | 
proxy 


Enables/ disables the forwarding of authenticated 
credentials to the origin content server or for proxy 
authentication. You can only choose one. 

• If set to origin, the spoofed header is an 
Authorization: header. 

• If set to proxy, the spoofed header is a 
Proxy-Authorization: header. 

• If set to none, no spoofing occurs. 

Flush the entries for a realm if the 
spoof -authentication value is changed to 
ensure that the spoof -authentication value is 
immediately applied. 


one -time -pas swords 


enable | 
disable 


Allows you to use one-time passwords for 
authentication. The default is disabled. For more 
information on one-time passwords, seethe 
RADIUS introduction on page 390. 



Creating the Policy 

Fine-tune RADIUS realms through attributes configured by policy — CPL or VPM. You can also create 
RADIUS groups. To fine-tune RADIUS realms, continue with the next section. To create RADIUS 
groups, see "Creating RADIUS Groups" on page 398. 



Note: RADIUS groups can only be configured through policy. This feature is not available 

through either the Management Console or the CLI. 
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Fine-Tuning RADIUS Realms 

Fine-tune RADIUS Realms by using the following attributes in the attribute . <name> and 
has_attribute . <name> CPL conditions and source objects in VPM. 



Table 9.2: RADIUS Attributes for the attribute. <name> and has_attribute.<name> Conditions 



RADIUS Attribute Name 


CPL Gesture Name 


Type (Possible Value) 


Callback-ID 


attribute. Callback-ID 


String 


Callback-Number 


attribute.Callback-Number 


String 


Filter-ID 


attribute . Filter-ID 


String 


Framed-IP- Address 


attribute. Framed-IP-Address 


IP Address 


Framed-IP-Netmask 


attribute.Framed-IP-Netmask 


IP Address 


Framed-MTU 


attribute . Framed-MTU 


Integer 


Framed-Pool 


attribute.Framed-Pool 


Strong 


Framed-Protocol 


attribute.Framed-Protocol 


Integer (1-6) 


Framed-Route 


attribute . Framed-Route 


String 


Idle-Timeout 


attribute. Idle-Timeout 


Integer 


Login-LAT-Group 


attribute.Login-LAT-Group 


String 


Login-L AT-N ode 


attribute.Login-LAT-Node 


String 


Login-LAT-Port 


attribute . Login-LAT-Port 


Integer 


Login-LAT-Service 


attribute . Login-LAT-Service 


String 


Login-IP-Host 


attribute.Login-IP-Host 


IP Address 


Login-Service 


attribute . Login-Service 


Integer (0-7) 


Login-TCP-Port 


attribute.Login-TCP-Port 


Integer (0-65535) 


Port-Limit 


attribute . Port-Limit 


Integer 


Service-Type 


attribute . Service-Type 


Integer (1-11) 


Session-Timeout 


attribute . Session-Timeout 


Integer 


Tunnel- Assignment-ID 


attribute. Tunnel- Assignment-ID 


String 


Tunnel-Medium-Type 


attribute.Tunnel-Medium-Type 


Integer (1-15) 


Tunnel-Private-Group-ID 


attribute.Tunnel-Private-Group-ID 


String 


Tunnel-Type 


attribute.Tunnel-Type 


Integer (1-12) 


Blue-Coat-Group 


attribute.Blue-Coat-Group 


String 
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Creating RADIUS Groups 

You can create a RADIUS realm group by using the custom Blue Coat attribute, which can appear 
multiple times within a RADIUS response. It can be used to assign a user to one or more groups. 
Values that are found in this attribute can be used for comparison with the group condition in CPL 
and the group object in VPM. The group name is a string with a length from 1-247 characters. The Blue 
Coat Vendor ID is 14501, and the Blue-Coat-Group attribute has a Vendor Type of 1. 

If you are already using the Filter-ID attribute for classifying users, you can use that attribute instead 
of the custom Blue-Coat-Group attribute. While the Filter-ID attribute does not work with the CPL 
group condition or the group object in VPM, the attribute . Filter- ID condition can be used to 
manage users in a similar manner. 

CPL Example 

Be aware that the examples below are just part of a comprehensive authentication policy. By 
themselves, they are not adequate. 



Note: Refer to the Blue Coat ProxySG Content Policy Language Guide for details about CPL and 

how transactions trigger the evaluation of policy file layers. 



□ Every RADIUS-authenticated user is allowed access the ProxySG if the RADIUS attribute 
service-type is set. 

< Proxy > 

authenticate (RADIUSRealm) 

< Proxy > 

allow has_attribute . Service-Type=yes 
deny 

□ A group called RegisteredUsersGroup is allowed to access the ProxySG if the allow group gesture 
is defined. 



<proxy> 

authenticate (RADIUSRealm) 

<proxy> 

allow group=RegisteredUsersGroup 
deny 

Troubleshooting 

One of five conditions can cause the following error message: 

Your request could not be processed because of a configuration error: "The request timed out while trying to 
authenticate. The authentication server may be busy or offline." 

□ The secret is wrong. 

□ The network is so busy that all packets were lost to the RADIUS server. 

□ The RADIUS server was slow enough that the ProxySG gave up before the server responded. 
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□ The RADIUS servers are up, but the RADIUS server is not running. In this case, you might also 
receive ICMP messages that there is no listener. 

□ RADIUS servers machines are not running/ unreachable. Depending on the network 
configuration, you might also receive ICMP messages. 
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Section F: Local Realm Authentication and Authorization 

Using a Local realm is appropriate when the network topography does not include external 
authentication or when you want to add users and administrators to be used by the SG appliance 
only. 

The Local realm (you can create up to 40) uses a Local User List, a collection of users and groups stored 
locally on the SG appliance. You can create up to 50 different Local User Lists. Multiple Local realms 
can reference the same list at the same time, although each realm can only reference one list at a time. 
The default list used by the realm can be changed at any time. 

This section discusses the following topics: 

□ "Creating a Local Realm" 

□ "Changing Local Realm Properties" 

□ "Defining the Local User List" 

□ "Creating the CPL" 

Creating a Local Realm 

To Create a Local Realm through the Management Console 
1. Select Configuration>Authentication>Local>Local Realms. 



Local Realms Local Main 




2. Click New; the Add Local Realm dialog displays. 
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Add Local Realm 



Realm name: | 

Other realm configuration parameters have been set to default values. 

OK | ( Cancel | 

Figure 9-31 : Add Local Realm 

3. In the Realm name field, enter a realm name. The name can be 32 characters long and composed of 
alphanumeric characters and underscores. The name must start with a letter. 

4. Click OK; click Apply. 

To Create a Local Realm through the CLI 

Up to 40 Local realms can be configured per ProxySG. 

At the (conf ig) command prompt, enter the following command to create a Local realm: 

SGOS# (config) security local create-realm realm_name 

where realm_name is the name of the new Local realm. 

Changing Local Realm Properties 

Once you have created a Local realm, you can modify the properties through the Management 
Console or the CLI. 

To Define or Change Local Realm Properties through the Management Console 
1. Select Configuration>Authentication>Local>Local Main. 



Local Realms Local Main 




r Virtual URL 



URL: 

Figure 9-32: Local Main Tab 
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Note: You must define a Local realm (using the Local Realms tab) before attempting to set realm 

properties. If the message Realms must be added in the Local Realms tab before 
editing this tab is displayed in red at the bottom of this page, you do not have a Local 
realm defined. 



2. Display name: The default value for the display name is the realm name. The display name cannot 
be longer than 128 characters and it cannot be null. 

3. Local User List: Specify the local user list from the drop-down list. 

4. Specify the length of time, in seconds, that user and administrator credentials received from the 
Local password file are cached. Credentials can be cached for up to 3932100 seconds. The default 
is 900 seconds (15 minutes). 

5. You can specify a virtual URL based on the individual realm. For information on using virtual 
URLs, see "Understanding Origin-Style Redirection" on page 326. 

6. Click Apply. 



To Define or Change Local Realm Properties through the CLI 



1. From the (config) prompt, enter the following commands to modify realm properties: 
SGOS# (config) security local edit-realm realm_name 



SGOS# (config local realm_name) 
SGOS# (config local realm_name ) 
SGOS# (config local realm_name ) 
SGOS# (config local realm_name ) 
SGOS# (config local realm_name ) 
SGOS# (config local realm_name ) 
SGOS# (config local realm_name) 
SGOS# (config local realm_name) 
SGOS# (config local realm_name) 



cache -duration 600 
display-name display_name 
local-user-list list_name 
rename new_realm_name 

spoof -authentication {disable [ enable} 
virtual -url url 

validate-authorized-user {disable | enable} 
default -group -name defaul t_group_name 
no default -group -name 



where: 



cache -duration 


seconds 


The number of seconds that user and administrator 
credentials received from the Local password file should 
be cached. The default is 900 seconds (15 minutes). 


display-name 


display name 


The display name for a realm, presented to the user as part 
of the authentication challenge, is equivalent to the 
display-name option in the CPL authenticate action. 
The default value for the display name is the realm name. 
The display name cannot be longer than 128 characters 
and it cannot be null. 


local -user -list 


list_name 


The list you want to associate with this realm. The list 
must exist before it is added. The local user list is set to the 
default list when the realm is created. For more 
information on creating a local list, see "Defining the Local 
User List" on page 404. 
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rename 


new realm 
name 


Allows you to change the realm name of an existing realm. 


spoof - 

authentication 


none | 
origin | 
proxy 


Enables /disables the forwarding of authenticated 
credentials to the origin content server or for proxy 
authentication. You can only choose one. 

• If set to origin, the spoofed header is an 
Authorization: header. 

• If set to proxy, the spoofed header is a 
Proxy-Authorization: header. 

• If set to none, no spoofing occurs. 

Flush the entries for a realm if the 

spoof -authentication value is changed to ensure that 
the spoof -authentication value is immediately 
applied. 


virtual-url 


URL 


The URL to redirect to when the user needs to be 
challenged for credentials. See Chapter 8: "Security and 
Authentication" on page 309 for more details. 


validate- 
authori zed- user 


enable | 
disable 


When validate-authorized-user is enabled, an 
authorization (not authentication) request will verify that 
the user exists in the local user list. If the user does not 
exist, the authorization request fails (authentication 
requests always require the user to exist). 

When validate-authorized-user is disabled, no 
user existence check is made for an authorization request. 
If the user does not exist, the authorization request 
succeeds. 


def ault -group - 
name 


group name 


If the validate-authorized-user command is 
disabled and a default-group-name is configured, the 
default-group-name is used as the group name for 
non-existent users. 


no 

def ault -group - 
name 




Clears the default group name. 



2 . 



(Optional) View the configuration: 

SGOS# (config local realm_name 
Realm name : 

Display name: 

Local user list: 

Cache duration: 

Virtual URL: 

Spoof authentication: 
Validate authorized user: 
Default group name : 



) view 

local_l 

local_l 

local_user_dat abase 
900 

none 

yes 
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Defining the Local User List 

Defining the local user list involves the following steps: 

□ Create a list or customize the default list for your needs. 

□ Upload a user list or add users and groups through the CLI. 

□ Associate the list with the realm. 

Creating a Local User List 

The user list local_user_database is created on a new system or after an upgrade. It is empty on a new 
system. If a password file existed on the ProxySG before an upgrade, then the list contains all users 
and groups from the password file; the initial default user list is local_user_database. If a new user 
list is created, the default can be changed to point to it instead by invoking the security 
local-user-list default list list name command. You can create up to 50 new lists with 10,000 
users each. 

Lists can be uploaded or you can directly edit lists through the CLI. If you want to upload a list, it 
must be created as a text file using the . htpasswd format of the ProxySG. 

Each user entry in the list consists of: 

□ username 

□ List of groups 

□ Hashed password 

□ Enabled / disabled boolean searches 

A list that has been populated looks like this: 

SGOS# (config) security local -user- list edit listname 

SGOS#(config local-user-list listname ) view 

list20 

Lockout parameters : 

Max failed attempts: 60 
Lockout duration: 3600 

Reset interval: 7200 

Users : 
adminl 

Hashed Password: $l$TvEzpZE$Z2A/OuJU3w5LnEONDHkmg . 

Enabled: true 
Groups : 
group 1 
admin2 

Hashed Password: $l$sKJvNB3r$xsInBU. /2hhBz6xDAHpND . 

Enabled: true 
Groups : 
group 1 
group2 
admin3 

Hashed Password: $l$duuCUt30$keSdIkZVS4RyFz47G78X20 
Enabled: true 
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Groups : 
group2 
Groups : 

group 1 
group2 

To create a new empty local user list: 

SGOS# (config) security local -user- list create listname 

Username 

The username must be case-sensitively unique, and can be no more than 64 characters long. All 
characters are valid, except for a colon ( : ). 

A new local user is enabled by default and has an empty password. 

List of Groups 

You cannot add a user to a group unless the group has previously been created in the list. The group 
name must be case-sensitively unique, and can be no more than 64 characters long. All characters are 
valid, except for colon ( : ). 

The groups can be created in the list; however, their user permissions are defined through policies 
only. 

Hashed Password 

The hashed password must be a valid UNIX DES or MD5 password whose plain-text equivalent 
cannot be more than 64 characters long. 

To populate the local user list using an off-box . htpasswd file, continue with the next section. To 
populate the local user list using the ProxySG CLI, go to "Defining the Local User List” on page 404. 

Populating a List using the .htpasswd File 

To add users to a text file in . htpasswd format, enter the following UNIX htpasswd command: 
prompt > htpasswd [-c] .htpasswd username 

The -c option creates a new .htpasswd file and should only be used for the very first . htpasswd 
command. You can overwrite any existing . htpasswd file by using the -c option. 

After entering this command, you are prompted to enter a password for the user identified by 
username. The entered password is hashed and added to the user entry in the text file. If the -m option 
is specified, the password is hashed using MD5; otherwise, UNIX DES is used 



Important: Because the -c option overwrites the existing file, do not use the option if you are 
adding users to an existing .htpasswd file. 



Once you have added the users to the .htpasswd file, you can manually edit the file to add user 
groups. When the .htpasswd file is complete, it should have the following format: 
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user : encrypted_password : groupl , group2 , ... 
user : encrypted_password : groupl , group2 , ... 



Note: You can also modify the users and groups once they are loaded on the ProxySG. To 

modify the list once it is on the ProxySG, see "Populating a Local User List through the 
ProxySG" on page 406. 



Uploading the .htpasswd File 

When the . htpasswd file is uploaded, the entries from it either replace all entries in the default local 
user list or append to the entries in the default local user list. One default local user list is specified on 
the ProxySG. 

To set the default local user list use the command security local-user-list default list 
listname. The list specified must exist. 

To specify that the uploaded . htpasswd file replace all existing user entries in the default list, enter 
security local-user-list default append-to-default disable before uploading 
the .htpasswd file. 

To specify that the . htpasswd file entries should be appended to the default list instead, enter 
security local-user-list default append-to-default enable. 

Uploading the .htpasswd File 

The .htpasswd file is loaded onto the ProxySG with a Perl script found at: 
http : / /download . bluecoat . com/release/ tools/ set_auth . zip 

Unzip the file, which contains the set_auth . pi script. 



Note: To use the set_auth .pi script, you must have Perl binaries on the system where the 

script is running. 



To Load the .htpasswd File 

prompt> set_auth.pl username password path_to_. htpasswd_file_on_local_machine 
ip_ address_of_the_ ProxySG 

where username and password are valid administrator credentials for the ProxySG. 

Populating a Local User List through the ProxySG 

You can populate a local user list from scratch or modify a local user list that was populated by 
loading an . htpasswd file. 

To Create a New, Empty Local User List 

SGOS# (config) security local -user- list create listname 
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To Modify an Existing Local User List (Can be Empty or Contain Users) 



1. From the (config) prompt, enter: 

SG0S# (config) security local -user- list edit listname 
SG0S# (config local-user-list listname) 



2 . 



To add users and groups to the list, enter the following commands, beginning with groups, since 
they must exist before you can add them to a user account. 



SG0S# (config local-user-list listname) 
ok 

SGOS# (config local-user-list listname) 
ok 

SGOS# (config local-user-list listname) 
ok 

SGOS# (config local-user-list listname ) 



group create groupl 
group create group2 
group create group3 
user create username 



3. Add the user information to the user account. 

SGOS# (config local-user-list listname ) user edit username 
SGOS# (config local-user-list listname username) group add groupnamel 
SGOS# (config local-user-list listname username) group add groupname2 
SGOS# (config local-user-list listname username) password password 
-or- 

SGOS# (config local-user-list listname username) hashed-password hashed-password 



Note: If you enter a plain-text password, the ProxySG hashes the password. If you enter a 

hashed password, the ProxySG does not hash it again. 



4. (Optional) The user account is enabled by default. To disable a user account: 

SGOS# (config local-user-list listname username) disable 
ok 

5. Repeat the above steps for each user you want added to the list. 

To View the Results of an Individual User Account 

Remain in the user account submode and enter the following command: 

SGOS# (config local-user-list listname username) view 
adminl 

Hashed Password: $l$TvEzpZE$Z2A/0uJU3w5LnE0NDHkmg . 

Enabled: true 
Failed Logins: 6 
Groups : 
groupl 



Note: If a user has no failed logins, the statistic does not display. 



To View the Users in the Entire List 

Exit the user account submode and enter: 
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listname username ) exit 
listname ) view 



SG0S#(config local-user-list 
SG0S#(config local-user-list 
list20 

Lockout parameters : 

Max failed attempts: 60 
Lockout duration: 3600 

Reset interval: 7200 

Users : 
adminl 

Hashed Password: $l$TvEzpZE$Z2A/OuJU3w5LnEONDHkmg . 
Enabled: true 
Groups : 
group 1 
admin2 

Hashed Password: $l$sKJvNB3r$xsInBU. /2hhBz6xDAHpND . 
Enabled: true 
Groups : 
groupl 
group2 
admin3 

Hashed Password: $l$duuCUt30$keSdIkZVS4RyFz47G78X20 
Enabled: true 
Groups : 
group2 
Groups : 
groupl 
group2 



To View all the Lists on the ProxySG 

SGOS# (config) show security local-user-list 

Default List : local_user_database 

Append users loaded from file to default list: false 
local_user_dat abase 
Lockout parameters : 

Max failed attempts: 60 
Lockout duration: 3600 

Reset interval: 7200 

Users : 

Groups : 
testl 
Users : 

Groups : 



To Delete Groups Associated with a User 

SGOS# (config local-user-list listname username ) group remove group_name 

To Delete Users from a List 

SGOS# (config local-user-list listname ) user delete username 
This will permanently delete the object. Proceed with deletion? 

(y or n) y 
ok 
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To Delete all Users from a List 

SGOS# (config local-user-list listname ) user clear 
ok 

The groups remain but have no users. 

To Delete all Groups from a List: 

SGOS# (config local-user-list listname ) group clear 
ok 



The users remain but do not belong to any groups. 



Enhancing Security Settings for the Local User List 

You can configure a local user database so that each user account is automatically disabled if too many 
failed login attempts occur for the account in too short a period, indicating a brute-force password 
attack on the ProxySG. The security settings are available through the CLI only. 

Available security settings are: 

□ Maximum failed attempts: The maximum number of failed password attempts allowed for an 
account. When this threshold is reached, the account is disabled (locked). If this is zero, there is no 
limit. The default is 60 attempts. 

□ Lockout duration: The time after which a locked account is re-enabled. If this is zero, the account 
does not automatically re-enable, but instead remains locked until manually enabled. The default 
is 3600 seconds (one hour). 

□ Reset interval: The time after which a failed password count resets after the last failed password 
attempt. If this is zero, the failed password count resets only when the account is enabled or when 
its password is changed. The default is 7200 seconds (two hours). 

These values are enabled by default on the system for all user account lists. You can change the 
defaults for each list that exists on the system. 



To Change the Security Settings for a Specific User Account List 



1. Enter the following commands from the (config) prompt: 

SGOS# (config) security local -user- list edit listname 
SGOS# (config local-user-list listname) lockout-duration seconds 
SGOS# (config local-user-list listname) max- failed-attempts attempts 
SGOS# (config local-user-list listname) reset- interval seconds 



2. (Optional) View the settings: 

SGOS# (config local-user-list listname) view 
listname 

Lockout parameters : 

Max failed attempts: 45 
Lockout duration: 3600 

Reset interval : 0 



3. (Optional) To disable any of these settings: 
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SGOS# (config local-user-list listname ) no [lockout-duration | 
max- failed-attempts | reset- interval] 

Creating the CPL 

Be aware that the examples below are just part of a comprehensive authentication policy. By 
themselves, they are not adequate for your purposes. (The default policy in these examples is deny.) 



Note: Refer to the Blue Coat ProxySG Content Policy Language Guide for details about CPL and 

how transactions trigger the evaluation of policy file layers. 



□ Every Local-authenticated user is allowed access the ProxySG. 

< Proxy > 

authenticate (LocalRealm) 

□ Group membership is the determining factor in granting access to the ProxySG. 

< Proxy > 

authenticate (LocalRealm) 

< Proxy > 

group="groupl" allow 

□ A subnet definition determines the members of a group, in this case, members of the Human 
Resources department. 

< Proxy > 

authenticate (LocalRealm) 

< Proxy > 

Define subnet HRSubnet 

192 . 168 . 0 . 0/16 

10 . 0 . 0 . 0/24 

End subnet HRSubnet 
[Rule] client_address=HRSubnet 
url . domain=monster . com 
url . domain=hot j obs . com 
deny 



[Rule] 

deny 
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Section G: Certificate Realm Authentication 

Certificate realms are used to authenticate users. If the users are members of an LDAP or Local group, 
the Certificate Realm can also forward the user credentials to the specified authorization realm, which 
determines the user's authorization (permissions). 

This section discusses the following topics: 

□ "How Certificate Realm Works" 

□ "Creating a Certificate Realm" 

□ "Defining a Certificate Realm" 

□ "Defining Certificate Realm General Properties" 

□ "Revoking User Certificates" 

How Certificate Realm Works 

Once an SSL session has been established, the user is asked to select the certificate to send to the SG 
appliance. If the certificate was signed by a Certificate Signing Authority that the SG appliance trusts, 
including itself, then the user is considered authenticated. The username for the user is the one 
extracted from the certificate during authentication. 

At this point the user is authenticated. If an authorization realm has been specified, such as LDAP or 
Local, the certificate realm then passes the username to the specified authorization realm, which 
figures out which groups the user belongs to. 



Note: If you authenticate with a certificate realm, you cannot also challenge for a password. 



Certificate realms do not require an authorization realm. If no authorization realm is configured, the 
user cannot be a member of any group. 

You do not need to specify an authorization realm if: 

□ The policy does not make any decisions based on groups 

□ The policy works as desired when all certificate realm-authenticated users are not in any group 
To use a Certificate Realm, you must: 

□ Configure SSL between the client and ProxySG (for more information, see "Using SSL Between the 
Client and the ProxySG" on page 329) 

□ Enable verity-client on the HTTPS service to be used (for more information, see "Managing the 
HTTPS Reverse Proxy" on page 169). 

□ Verify that the certificate authority that signed the client's certificates is in the ProxySG trusted list. 
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Creating a Certificate Realm 

To Create a Certificate Realm through the Management Console 
1. Select Configuration>Authentication>Certificate>Certificate Realms. 

Certificate Realms j Certificate Main | Certificate General 

r Certificate Realms: 




Figure 9-33: Certificate Realms Tab 
2. Click New; the Add Certificate Realm dialog displays. 




Figure 9-34: Add Certificate Realm 

3. In the Realm name field, enter a realm name. The name can be 32 characters long and composed of 
alphanumeric characters and underscores. The name must start with a letter. 

4. Click OK; click Apply. 

To Create a Certificate Realm through the CLI 

Up to 40 Certificate realms can be configured per ProxySG. 

At the (conf ig) command prompt, enter the following command to create a Certificate realm: 

SGOS# (config) security certificate create-realm realm_name 

where realm name is the name of the new Certificate realm. 
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Defining a Certificate Realm 

To Define Certificate Authentication Properties through the Management Console 



Note: You can also define certificate authentication properties through the CLI. For information, 

see "To Create and Define a Certificate Realm through the CLI" on page 414. 



1. Select Configuration>Authentication>Certificate>Certificate Main. 

Certificate Realms Certificate Main | Certificate General 

Realm name: 

Authorization Realm Name: 

Username attribute: 

Container attribute list: 
pi Append Base DN 
Base DN: 

Cache credentials 900 J seconds 

Figure 9-35: Certificate Main Tab 

2. From the Realm Name drop-down list, select the Certificate realm for which you want to change 
realm properties. 



Note: You must have defined at least one Certificate realm (using the Certificate Realms tab) 

before attempting to set Certificate realm properties. If the message Realms must be 
added in the Certificate Realms tab before editing this tab is displayed in 
red at the bottom of this page, you do not currently have any Certificate realms defined. 



3. (Optional) From the Authorization Realm Name drop-down list, select the LDAP or Local realm you 
want to use to authorize users. 

4. From the username attribute field, enter the attribute that specifies the common name in the subject 
of the certificate. CN is the default. 

5. (Optional, if you are configuring a Certificate realm with LDAP authorization) Enter the list of 
attributes (the container attribute field) that should be used to construct the user's distinguished 
name. 

For example, $(OU) $(0) substitutes the OU and O fields from the certificate. 

6. (Optional, if you are configuring a Certificate realm with LDAP authorization) Select or deselect 
Append Base DN. 

7. (Optional, if you are configuring a Certificate realm with LDAP authorization) Enter the Base DN 
where the search starts. If no BASE DN is specified and Append Base DN is enabled, the first Base 
DN defined in the LDAP realm used for authorization is appended. 



None 



CN 
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8. Cache credentials: Specify the length of time, in seconds, that user and administrator credentials 
received from the Local password file are cached. Credentials can be cached for up to 3932100 
seconds. The default is 900 seconds (15 minutes). 

Defining Certificate Realm General Properties 

The Certificate General tab allows you to specify the display name and a virtual URL. 

To Configure Certificate Realm General Settings through the Management Console 

1. Select Configuration>Authentication>Certificate>Certificate General. 

Certificate Realms j Certificate Main Certificate General 



certificate! 



Display name: j certificate! ] 

r Virtual URL 

URL 1 I 

Figure 9-36: Certificate General Tab 

2. From the Realm name drop-down list, select the Certificate realm for which to change properties. 

Note: You must have defined at least one Certificate realm (using the Certificate Realms tab) 

before attempting to set Certificate general properties. If the message Realms must be 
added in the Certificate Realms tab before editing this tab is displayed in 
red at the bottom of this page, you do not currently have any Certificate realms defined. 

3. If needed, change the Certificate realm display name. The default value for the display name is 
the realm name. The display name cannot be longer than 128 characters and it cannot be null. 

4. You can specify a virtual URL based on the individual realm. For more information on the virtual 
URL, see "Understanding Origin-Style Redirection" on page 326. 

5. Click Apply. 

To Create and Define a Certificate Realm through the CLI 

1. At the (config) prompt: 

SGOS# (config) security certificate create-realm realm_name 

2. To define an authorization realm for the Certificate realm configuration for the realm you just 
created, enter the following commands: 

SGOS# (config) security certificate edit-realm realm_name 

SGOS# (config certificate realm_name) authorization { append-base-dn {enable | 
disable | dn dn_to_append } | container-attr-list list | realm-name realm | 

username-attribute attribute} 
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where: 



append-base-dn 


enable | 
disable | dn 
dn_to_append 


Used only if an LDAP authorization realm is present. 


container- at tr- 
list 


list 


Used only if an LDAP authorization realm is present. If the 
CLI contains spaces, quotes must be used, as in 
"ou=Research and Development, ou=Sales, o=Blue 
Coat" . 


realm-name 


realm name 


The name of the LDAP or Local realm used for 
authorization. The realm name must already exist. 


username - 
attribute 


attribute 


The attribute that specifies the common name in the subject 
of the certificate. CN is the default. 



3. Enter the following commands to modify Certificate realm properties: 

SGOS# (config certificate realm_name ) cache-duration 600 

SGOS# (config certificate new_realm_name) virtual-url cfauth.com 

SGOS# (config certificate new_realm_name ) display-name display_name 

where: 



cache -duration 


seconds 


The number of seconds that user and administrator 
credentials received from the Credential realm are cached. 
The default is 9 00 seconds (15 minutes). 


virtual-url 


URL 


The URL to redirect to when the user needs to be 
challenged for credentials. See Chapter 8: "Security and 
Authentication" on page 309 for more details. 


display-name 


display_name 


The default value for the display name is the realm name. 
The display name cannot be longer than 128 characters and 
it cannot be null. 



4. (Optional) View the results: 

SGOS# (config certificate certificate-name) view 



Realm name : 

Display name: 

Cache duration: 
Virtual URL: 
Authorization realm: 
Username attribute : 
Container attr. list: 
Append DN : 

Base DN: 



certificate -name 
certificate -name 
900 

cf auth . com 
ldap-realm 
cn 

ou=Sales , ou=Manuf acturing 
enabled 
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Revoking User Certificates 

Using policy, you can revoke certain certificates by writing policy that denies access to users who have 
authenticated with a certificate you want to revoke. You must maintain this list on the ProxySG; it is 
not updated automatically. 



Note: This method of revoking user certificates is meant for those with a small number of 

certificates to manage. 

For information on using automatically updated lists, see "Using Certificate Revocation 
Lists" on page 286. 



A certificate is identified by its issuer (the Certificate Signing Authority that signed it) and its serial 
number, which is unique to that CA. 

Using that information, you can use the following strings to create a policy to revoke user certificates: 

□ user . x5 0 9 . serialNumber — This is a string representation of the certificate's serial number in 
HEX. The string is always an even number of characters long, so if the number needs an odd 
number of characters to represent in hex, there is a leading zero. Comparisons are case insensitive. 

□ user .x509 . issuer — This is an RFC2253 LDAP DN. Comparisons are case sensitive. 

□ (optional) user .x509 . subject: This is an RFC2253 LDAP DN. Comparisons are case sensitive. 

Example 

If you have only one Certificate Signing Authority signing user certificates, you do not need to test the 
issuer. In the < Proxy > layer of the Local Policy file: 

<proxy> 

deny user . x509 . serialnumber=ll 
deny user . x509 . serialNumber=OF 

If you have multiple Certificate Signing Authorities, test both the issuer and the serial number. In the 
< Proxy > layer of the Local Policy file: 

<proxy> 

deny user . x509 . issuer= "Email=name , CN=name , OU=name , O=company , L=city , ST= state or 
province , C=country" user . x509 . serialnumber=ll\ 

deny user . x509 . issuer= " CN=name , OU=name , O=company , L=city, ST=state or 
province , C=country" \ 

deny user . x509 . serialnumber=2CB06E9FOOOOOOOOOOOB 

Creating the Certificate Authorization Policy 

When you complete Certificate realm configuration, you can create CPL policies. Be aware that the 
examples below are just part of a comprehensive authentication policy. By themselves, they are not 
adequate. 
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Note: Refer to the Blue Coat ProxySG Content Policy Language Guide for details about CPL and 

how transactions trigger the evaluation of policy file <Proxy> and other layers. 



Be aware that the default policy condition for these examples is allow. On new SGOS4.X systems, the 
default policy condition is deny. 

□ Every Certificate realm authenticated user is allowed access the ProxySG. 

< Proxy > 

authenticate (Certif icateRealm) 

□ A subnet definition determines the members of a group, in this case, members of the Human 
Resources department. (They are allowed access to the two URLs listed. Everyone else is denied 
permission.) 

< Proxy > 

authenticate (Certif icateRealm) 

< Proxy > 

Define subnet HRSubnet 

192 . 168 . 0 . 0/16 

10 . 0 . 0 . 0/24 

End subnet HRSubnet 
[Rule] client_address=HRSubnet 
url . domain=monster . com 
url . domain=hot j obs . com 
deny 



[Rule] 

deny 

Tips 

If you use a certificate realm and see an error message similar to the following 

Realm configuration error for realm "cert": connection is not SSL. 

This means that certificate authentication was requested for a transaction, but the transaction was not 

done on an SSL connection, so no certificate was available. 

This can happen in three ways: 

□ The authenticate mode is either origin-IP-redirect/origin-cookie-redirect or 
origin-lP/origin-cookie, but the virtual URL does not have an https : scheme. This is likely if 
authentication through a certificate realm is selected with no other configuration, because the 
default configuration does not use SSL for the virtual URL. 

□ In a server accelerator deployment, the authenticate mode is origin and the transaction is on a 
non-SSL port. 
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□ The authenticate mode is origin - IP -redirect /origin- cookie -redirect, the user has 
authenticated, the credential cache entry has expired, and the next operation is a POST or PUT 
from a browser that does not handle 307 redirects (that is, from a browser other than Internet 
Explorer). The workaround is to visit another URL to refresh the credential cache entry and then 
try the POST again. 

□ Forms authentication modes cannot be used with a Certificate realm. If a form mode is in use and 
the authentication realm is a Certificate realm, a Policy Substitution realm, or an IWA realm, you 
receive a configuration error. 
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Section H: Netegrity SiteMinder 

The ProxySG can be configured to consult a SiteMinder policy server for authentication and session 
management decisions. This requires that a SiteMinder realm be configured on the ProxySG and 
policy written to use that realm for authentication. 

Access to the SiteMinder policy server is done through the Blue Coat Authentication and 
Authorization Agent (BCAAA), which must be installed on a Windows 2000 system or higher with 
access to the SiteMinder policy servers. 

Understanding SiteMinder Interaction with Blue Coat 

Within the SiteMinder system, BCAAA acts as a custom Web agent. It communicates with the 
SiteMinder policy server to authenticate the user and to obtain a SiteMinder session token, response 
attribute information, and group membership information. 

Custom header and cookie response attributes associated with OnAuthAccept and OnAccessAccept 
attributes are obtained from the policy server and forwarded to the SG appliance. They can (as an 
option) be included in requests forwarded by the appliance. 

Within the SG system, BCAAA acts as its agent to communicate with the SiteMinder server. The SG 
appliance provides the user information to be validated to BCAAA, and receives the session token 
and other information from BCAAA. 

Each SG SiteMinder realm used causes the creation of a BCAAA process on the Windows host 
computer running BCAAA. A single host computer can support multiple SG realms (from the same or 
different SG appliances); the number depends on the capacity of the BCAAA host computer and the 
amount of activity in the realms. 



Note: Each (active) SiteMinder realm on the SG appliance should reference a different agent on 

the Policy Server. 



Configuration of the SG's realm must be coordinated with configuration of the SiteMinder policy 
server. Each must be configured to be aware of the other. In addition, certain SiteMinder responses 
must be configured so that BCAAA gets the information the SG appliance needs. 

Configuring the SiteMinder Policy Server 



Note: Blue Coat assumes you are familiar with configuration of SiteMinder policy servers and 

Web agents. 



Since BCAAA is a Web agent in the SiteMinder system, it must be configured on the SiteMinder policy 
server. Configuration of BCAAA on the host computer is not required; the agent obtains its 
configuration information from the ProxySG. 
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A suitable Web agent must be created and configured on the SiteMinder server. This must be 
configured to support 4.x agents, and a shared secret must be chosen and entered on the server (it 
must also be entered in the ProxySG SiteMinder realm configuration). 

SiteMinder protects resources identified by URLs. A ProxySG realm is associated with a single 
protected resource. This could be an already existing resource on a SiteMinder server, (typical for a 
reverse proxy arrangement) or it could be a resource created specifically to protect access to ProxySG 
services (typical for a forward proxy). 



Important: The request URL is not sent to the SiteMinder policy server as the requested 
resource; the requested resource is the entire ProxySG realm. Access control of 
individual URLs is done on the ProxySG using CPL or VPM. 



The SiteMinder realm that controls the protected resource must be configured with a compatible 
authentication scheme. The supported schemes are Basic (in plain text and over SSL), Forms (in plain 
text and over SSL), and X.509 certificates. Configure the SiteMinder realm with one of these 
authentication schemes. 



Note: Only the following X.509 Certificates are supported: X.509 Client Cert Template, X.509 

Client Cert and Basic Template, and X.509 Client Cert and Form Template. 



ProxySG requires information about the authenticated user to be returned as a SiteMinder response. 
The responses should be sent by an OnAuthAccept rule used in the policy that controls the protected 
resource. 

The responses must include the following: 

□ A Web-Agent-HTTP-Header-variable named bcsi_username. It must be a user attribute; the 
value of the response must be the simple username of the authenticated user. For example, with 
an LDAP directory this might be the value of the cn attribute or the uid attribute. 

□ A Web-Agent-HTTP-Header-variable named bcsi_groups. It must be a user attribute and the 
value of the response must be smjjsergroups. 

If the policy server returns an LDAP FQDN as part of the authentication response, the ProxySG uses 
that LDAP FQDN as the FQDN of the user. 

Once the SiteMinder agent object, configuration, realm, rules, responses and policy have been 
defined, the ProxySG can be configured. 

Additional SiteMinder Configuration Notes 



Note: Additional configuration might be needed on the SiteMinder server depending on 

specific features being used. 
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□ If using single-signon (SSO) with off-box redirection (such as to a forms login page), the forms 
page must be processed by a 5.x or later Web Agent, and that agent must be configured with 

f cccompatmode=no. This precludes that agent from doing SSO with 4.x agents. 

□ For SSO to work with other Web agents, the other agents must have the AcceptTPCookie=YES as 
part of their configuration. This is described in the SiteMinder documentation. 

□ Blue Coat does not extract the issuerDN from X.509 certificates in the same way as the SiteMinder 
agent. Thus, a separate certificate mapping might be needed for the SGOS agent and the 
SiteMinder agents. 

For example, the following was added to the SiteMinder policy server certificate mappings: 

CN=Waterloo Authentication and Security Team, OU=Waterloo R&D, 0=Blue Coat\, 

Inc . , L=Waterloo, ST=ON, C=CA 

□ In order to use off-box redirection (such as an SSO realm), all agents involved must have the 
setting EncryptAgentName=no in their configurations. 

□ The ProxySG Appliance's credential cache only caches the user's authentication information for 
the smaller of the time-to-live (TTL) configured on the ProxySG and the session TTL configured 
on the SiteMinder policy server. 

Configuring the ProxySG Realm 

The ProxySG realm must be configured so that it can: 

□ Find the Blue Coat agent(s) that acts on its behalf (hostname or IP address, port, SSL options, and 
the like). 

□ Provide BCAAA with the information necessary to allow it to identify itself as a Web agent (agent 
name, shared secret). 

□ Provide BCAAA with the information that allows it to find the SiteMinder policy server (IP 
address, ports, connection information.) 

□ Provide BCAAA with the information that it needs to do authentication and collect authorization 
information (protected resource name), and general options (server fail-over and off-box 
redirection) 

For more information on configuring the ProxySG SiteMinder realm, see "Creating a SiteMinder 
Realm" on page 423. 



Note: All ProxySG and agent configuration is done on the ProxySG. The ProxySG sends the 

necessary information to BCAAA when it establishes communication. 



Participating in a Single Sign-On (SSO) Scheme 

The ProxySG can participate in SSO with other systems that use the same SiteMinder policy server. 
Users must supply their authentication credentials only once to any of the systems participating. 
Participating in SSO is not a requirement, the Proxy SG can use the SiteMinder realm as an ordinary 
realm. 
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When using SSO with SiteMinder, the SSO token is carried in a cookie (smsession). This cookie is set 
in the browser by the first system that authenticates the user; other systems obtain authentication 
information from the cookie and so do not have to challenge the user for credentials. The ProxySG sets 
the SMSESSION cookie if it is the first system to authenticate a user, and authenticates the user based on 
the cookie if the cookie is present. 

Since the SSO information is carried in a cookie, all the servers participating must be in the same 
cookie domain, including the ProxySG. This imposes restrictions on the authenticate .mode ( ) used 
on the ProxySG. 

□ A reverse proxy can use any origin mode. 

□ A forward proxy must use one of the origin- redirect modes (such as 
origin-cookie-redirect). When using origin- * -redirect modes, the virtual URL hostname 
must be in the same cookie domain as the other systems. It cannot be an IP address and the 
default www . cf auth . com does not work either. 

When using origin- * -redirect, the SSO cookie is automatically set in an appropriate response after 
the ProxySG authenticates the user. When using origin mode (in a reverse proxy), setting this cookie 
must be explicitly specified by the administrator. The policy substitution variable 
$ (x-agent-sso-cookie) expands to the appropriate value of the set-cookie: header. 

Avoiding ProxySG Challenges 

In some SiteMinder deployments all credential challenges are issued by a central authentication 
service (typically a Web server that challenges through a form). Protected services do not challenge 
and process request credentials; instead, they work entirely with the SSO token. If the request does not 
include an SSO token, or the SSO token is not acceptable, the request is redirected to the central 
service, where authentication occurs. Once authentication is complete, the request is redirected to the 
original resource with a response that sets the SSO token. 

If the SiteMinder policy server is configured to use a forms-based authentication scheme, the above 
happens automatically. However, in this case, the ProxySG realm can be configured to redirect to an 
off-box authentication service always. The URL of the service is configured in the scheme definition 
on the SiteMinder policy server. The ProxySG realm is then configured with 
always-redirect-of fbox enabled. 

The ProxySG must not attempt to authenticate a request for the off-box authentication URL. If 
necessary, authenticate (no) can be used in policy to prevent this. 
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Creating a SiteMinder Realm 

To Create a SiteMinder Realm through the Management Console 
1. Select Configuration>Authentication>Netegrity SiteMinder>SiteMinder Realms. 



SiteMindei Realms | Agents | SiteMinder Servers | SiteMinder S^ < | ► 




2. Click New; the Add SiteMinder Realm dialog displays. 



Add SiteMinder Realm 



Realm name: 



Other realm configuration parameters have been set to default values. 

( OK ] ( Cancel J 

Figure 9-38: Add SiteMinder Realm 

3. In the Realm name field, enter a realm name. The name can be 32 characters long and composed of 
alphanumeric characters and underscores. The name must start with a letter. The name should be 
meaningful to you, but it does not have to be the name of the SiteMinder policy server. 

4. Click OK. 

5. Click Apply. 

To Create a SiteMinder Realm through the CLI 

At the (conf ig) prompt, enter the following command to create a SiteMinder realm: 

SGOS# (config) security siteminder create-realm realm_name 

where realm__name is the name of the SiteMinder realm. 

Configuring Agents 

You must configure the SiteMinder realm so that it can find the Blue Coat Authentication and 
Authorization Agent (BCAAA). 
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1. Select Configuration>Authentication>Netegrity SiteMinder>Agents. 

SiteMinder Realms Agents j SiteMinder Servers | SiteMinder Se’ < | t 



Realm name: 

Primary agent 
Host: 



Agent name: 



Alternate agent 
Host: 



Agent name: 



SSL Options 



Port: 16101 ] 



Change Secret 



Port: [ 16101 



Change Secret 



1~1 Enable SSL 

Figure 9-39: SiteMinder Agents Page 
2. Select the realm name to edit from the drop-down list. 



Note: You must have defined at least one SiteMinder realm (using the SiteMinder Realms tab) 

before attempting to configure SiteMinder agents. If the message Realms must be added 
in the SiteMinder Realms tab before editing this tab is displayed in red at the 
bottom of this page, you do not currently have any SiteMinder realms defined. 



3. In the Primary agent section, enter the hostname or IP address where the agent resides. 

4. Change the port from the default of 16101 if necessary. 

5. Enter the agent name in the Agent name field. The agent name is the name as configured on the 
SiteMinder policy server. 

6. You must create a secret for the Agent that matches the secret created on the SiteMinder policy 
server. Click Change Secret. SiteMinder secrets can be up to 64 characters long and are always case 
sensitive. 

7. (Optional) Enter an alternate agent host and agent name in the Alternate agent section. 

8. (Optional) Click Enable SSL to enable SSL between the ProxySG and the BCAAA. 

9. (Optional) By default, if SSL is enabled, the SiteMinder BCAAA certificate is verified. To not 
verify the agent certificate, disable this setting. 

To Edit a SiteMinder Agent through the CLI 

1. To define the primary and alternate agent configuration for the realm you just created, enter the 
following commands at the (config) prompt: 
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SGOS# (config) security 
SGOS#(config siteminder 
SGOS# (config siteminder 
SGOS# (config siteminder 
SGOS# (config siteminder 
encrypt ed_shared_sec ret 
-or- 

SGOS# (config siteminder 
SGOS# (config siteminder 
SGOS# (config siteminder 
SGOS# (config siteminder 
SGOS# (config siteminder 
encrypt ed_shared_secret 
-or- 

SGOS# (config siteminder 



siteminder edit-realm realm_name 
realm_name) primary-agent agent-name agent_name 
realm_name) primary-agent host host_name_or_IP_address 
realm_name ) primary-agent port port_number 
realm_name ) primary-agent encrypted- shared- secret 



realm_name ) primary-agent shared-secret shared_secret 



realm_name ) 
realm_name ) 
realm_name ) 
realm_name ) 



alternate-agent agent-name agent_name 
alternate-agent host host_name_or_IP 
alternate-agent port port_number 
alternate -agent encrypted- shared- secret 



realm_name ) alternate-agent shared-secret shared_secret 



where: 



primary- agent | 
alternate agent 




These commands allow you to configure either 
the primary or alternate agent for the SiteMinder 
realm. 


agent -name 


agent name 


The name of the agent. 


host 


host name or 
_IP_address 


The host ID or the IP address of the system that 
contains the agent. 


port 


port number 


The port where the agent listens. 


encrypted- shared- secret 
| shared- secret 


secret 


The shared secret (or encrypted secret) associated 
with the primary or alternate agent. (Secrets can 
be up to 64 characters long and are always case 
sensitive.) 

The primary use of the encrypted-password 
command is to allow the ProxySG to reload a 
password that it encrypted. You can choose to 
use a third-party encryption application. The 
encrypted password is encrypted using RSA 
with OAEP padding, and is Base64 encoded with 
no newlines. 



2. To enable SSL for this realm and to have the BCAAA certificate verified, enter: 

SGOS# (config siteminder realm_name ) ssl enable 

SGOS# (config siteminder realm_name) ssl-verify-agent enable 



Note: The ssl-verify-server command in authentication is not overridden by the CPL 

property server . certificate .validate or the forwarding hosts ssl-verify-server 
command. 
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Configuring SiteMinder Servers 

Once you create a SiteMinder realm, use the SiteMinder Servers page to create and edit the list of 
SiteMinder policy servers consulted by the realm. 

1. Select Configuration>Authentication>Netegrity SiteMinder>SiteMinder Servers. 

SiteMinder Realms | Agents SiteMinder Servers j SiteMinder Se' < | > 

Realm name: v 

r SiteMinder Servers 




Figure 9-40: SiteMinder Servers Tab 

2. From the Realm Name drop-down list, select the SiteMinder realm for which you want to add 
servers or change server properties. 



Note: You must have defined at least one SiteMinder realm (using the SiteMinder Realms page) 

before attempting to set SiteMinder policy server properties. If the message Realms must 
be added in the SiteMinder Realms tab before editing this tab is displayed in 
red Click Apply. Repeat the above steps for additional SiteMinder realms, up to a total of 
40. 



3. To create a new SiteMinder policy server, click New. 
The Add List dialog displays. 



Add SiteMinder Realm 



Realm name: 



Other realm configuration parameters have been set to default values. 



( OK ] [ Cancel ] 

Figure 9-41 : SiteMinder Add List Item Dialog 
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a. Enter the name of the server in the dialog. This name is used only to identify the server in 
the ProxySG Appliance's configuration; it usually is the real hostname of the SiteMinder 
policy server. 

b. Click OK. 

4. To edit an existing SiteMinder policy server, click Edit. 

The Edit dialog displays. 




Figure 9-42: SiteMinder Edit Server Dialog 

a. Enter the IP address of the SiteMinder policy server in the IP address field. 

b. Enter the correct port number for the Authentication, Authorization, and Accounting ports. The 
ports should be the same as the ports configured on their SiteMinder policy server. The 
valid port range is 1-65535. 

c. The maximum number of connections is 32768; the default is 256. 

d. The connection increment specifies how many connections to open at a time if more are 
needed and the maximum is not exceeded. The default is 1 . 

e. The timeout value has a default of 60 seconds, which can be changed. 

5. Click OK. 

6. Click Apply. 

Editing SiteMinder Policy Servers through the CLI 

To create and edit the SiteMinder policy server for the realm you just created, enter the following 

commands: 



Note: The only required option is the IP address. The other options need only be used if you 

want to change the defaults. 
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SGOS# (config) 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 



security siteminder edit-realm realm_name 
siteminder realm_name) siteminder- server create server_name 
siteminder realm name) siteminder- server edit server name 



siteminder realm_name server_name ) 
siteminder realm_name server_name ) 
siteminder realm_name server_name ) 
siteminder realm_name server_name) 
siteminder realm_name server_name) 
siteminder realm_name server_name) 
siteminder realm_name server_name) 
siteminder realm name server name) 



ip -address ip_address 
authentication-port port_number 
authorization-port port_number 
accounting-port port_number 
connection- increment number 
max- connections number 
min- connections number 
timeout seconds 



where: 



siteminder- 

server 


create server name \ 
edit server name \ 
delete 


You can create a SiteMinder policy server, edit 
it, or delete it. 


edit 

server name 


ip-address ip_address 


The IP address of the SiteMinder policy server. 


edit 

server name 


authenti cat ion -port 
port number 


The default is 44442. The ports should be the 
same as the ports configured on the SiteMinder 
policy server. The valid port range is 1-65535. 


edit 

server name 


authorization- port 
port number 


The default is 44443. The ports should be the 
same as the ports configured on the SiteMinder 
policy server. The valid port range is 1-65535. 


edit 

server name 


accounting -port 
port number 


The default is 44441. The ports should be the 
same as the ports configured on the SiteMinder 
policy server. The valid port range is 1-65535. 


edit 

server name 


connection- increment 
number 


The default is 1. The connection increment 
specifies how many connections to open at a 
time if more are needed and the maximum is 
not exceeded. 


edit 

server name 


max-connections number 


The default is 256. The maximum number of 
connections is 32768. 


edit 

server name 


min-connections number 


The default is 1. 


edit 

server name 


timeout seconds 


The default is 60. 



To View the SiteMinder Policy Server Configuration: 

SGOS# (config siteminder realm_name server_name) 



Server name: 

IP address: 

Min connections: 
Max connections: 



test 

10 . 25 . 36.47 

1 

256 



view 
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Connection inc : 1 

Timeout: 60 

Authentication Port: 44442 
Authorization Port: 44443 

Accounting Port: 44441 



Defining SiteMinder Server General Properties 

The SiteMinder Server General tab allows you to specify the protected resource name, the server mode, 
and whether requests should always be redirected off box. 

To Configure General Settings through the Management Console 

1. Select Configuration>Authentication>Netegrity SiteMinder>SiteMinder Server General. 

Realms | Agents | SiteMinder Servers SiteMinder Server General < | > 




Q Add header responses from server 
0 Validate client IP address 

Figure 9-43: SiteMinder Server General Tab 

2. From the Realm Name drop-down list, select the SiteMinder realm for which you want to change 
properties. 



Note: You must have defined at least one SiteMinder realm (using the SiteMinder Realms tab) 

before attempting to set SiteMinder general properties. If the message Realms must be 
added in the SiteMinder Realms tab before editing this tab is displayed in red 
at the bottom of this page, you do not currently have any SiteMinder realms defined. 



3. Enter the protected resource name. The protected resource name is the same as the resource name 
on the SiteMinder policy server that has rules and policy defined for it. 

4. In the Server mode drop-down list, select either failover or round-robin. Failover mode falls back to 
one of the other servers if the primary one is down. Round-robin modes specifies that all of the 
servers should be used together in a round-robin approach. Failover is the default. 



Note: The server mode describes the way the agent (BCAAA) interacts with the SiteMinder 

policy server, not the way that ProxySG interacts with BCAAA. 



5. To force authentication challenges to always be redirected to an off-box URL, select Always redirect 
off-box. 
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Note: All SiteMinder Web agents involved must have the setting EncryptAgentName=no in their 

configurations to go off-box for any reason. 



If using SiteMinder forms for authentication, the ProxySG always redirects the browser to the 
forms URL for authentication. You can force this behavior for other SiteMinder schemes by 
configuring the always redirect off-box property on the realm. 

6. If your Web applications need information from the SiteMinder policy server responses, you can 
select Add Header Responses. Responses from the policy server obtained during authentication are 
added to each request forwarded by the ProxySG. Header responses replace any existing header 
of the same name; if no such header exists, the header is added. Cookie responses replace a cookie 
header with the same cookie name; if no such cookie header exists, one is added. 

7. To enable validation of the client IP address, select Validate client IP address. If the client IP address 
in the SSO cookie can be valid yet different from the current request client IP address, due to 
downstream proxies or other devices, deselect Validate client IP address for the realm. SiteMinder 
agents participating in SSO with the ProxySG should also be modified; set the TransientIPCheck 
variable to yes to enable IP address validation and no to disable it. 

8. Click Apply. 

To Configure General Settings through the CLI 

At the (conf ig) command prompt, enter the following commands to configure general server 
settings: 

SGOS# (config siteminder realm_name ) protected-resource-name 
protec ted_resource_name 

SGOS# (config siteminder realm_name ) server-mode { failover | round-robin} 

(Optional) SGOS# (config siteminder realm_name ) always-redirect-of fbox {enable | 
disable} 

(Optional) SGOS# (config siteminder realm_name ) add-header-responses {enable | 
disable} 

(Optional) SGOS# (config siteminder realm_name) validate -client- IP {disable | 
enable } 



where: 



protected-resource- 

name 


protected_resource_ 

name 


The resource name on the SiteMinder 
policy server that has rules and policy 
defined for it. 


server-mode 


failover | 
round- robin 


Behavior of the server. Failover mode falls 
back to one of the other servers if the 
primary one is down. Round-robin modes 
specifies that all of the servers should be 
used together in a round-robin approach. 
Failover is the default. 
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always- redirect - 
of fbox 


enable | disable 


If using SiteMinder forms for 
authentication, the ProxySG always 
redirects the browser to the forms URL for 
authentication. You can force this behavior 
for other SiteMinder schemes by 
configuring the always redirect off -box 
property on the realm. 

All agents involved must have the setting 
EncryptAgentName=no in their 
configurations to go off-box for any 
reason. 


add-header -responses 


enable | disable 


Enable if your Web applications need 
information from the SiteMinder policy 
server responses. Header responses 
replace any existing header of the same 
name; if no such header exists, the header 
is added. Cookie responses replace a 
cookie header with the same cookie name; 
if no such cookie header exists, one is 
added. 


validate -client -IP 


enable | disable 


Enables validation of the client IP address. 
If the client IP address in the SSO cookie 
can be valid yet different from the current 
request client IP address, due to 
downstream proxies or other devices, 
disable client IP validation. The 
SiteMinder agents participating in SSO 
with the ProxySG should also be modified. 
Set the TransientIPCheck variable to yes 
to enable IP validation and no to disable it. 



Configuring General Settings for SiteMinder 

The SiteMinder General tab allows you to set a display name, cache credentials, timeout value, and 
create a virtual URL. 

To Manage General Settings for the SiteMinder realm 
1. Select Authentication>Netegrity SiteMinder>SiteMinder General. 
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SiteMinder Servers 



SiteMinder Server General 



SiteMinder General ^ | ► 



Realm name: 



Display name: SMI 



Timeout request after 60 seconds 



Cache credentials 900 j seconds 




I | Case sensitive 



Figure 9-44: SiteMinder General Page 

2. From the Realm Name drop-down list, select the SiteMinder realm for which you want to change 
properties. 



Note: You must have defined at least one SiteMinder realm (using the SiteMinder Realms tab) 

before attempting to set SiteMinder general properties. If the message Realms must be 
added in the SiteMinder Realms tab before editing this tab is displayed in red 
at the bottom of this page, you do not currently have any SiteMinder realms defined. 



3. If needed, change the SiteMinder realm display name. The default value for the display name is 
the realm name. The display name cannot be longer than 128 characters and it cannot be null. 

4. Specify the length of time, in seconds, that user and administrator credentials received from the 
SiteMinder policy server are cached. Credentials can be cached for up to 3932100 seconds. The 
default cache-duration is 900 seconds (15 minutes). 

5. If you want group comparisons for SiteMinder groups to be case sensitive, select Case sensitive. 

6. The virtual hostname must be in the same cookie domain as the other servers participating in the 
SSO. It cannot be an IP address or the default, www . cf auth . com. 

7. Click Apply. 



To Set SiteMinder General Settings through the CLI 



At the (conf ig) command prompt, enter the following commands to configure general server 
settings: 



SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 



siteminder 

siteminder 

siteminder 

siteminder 



realm_name) 
realm_name ) 
realm_name) 
realm_name) 



cache-duration seconds 
case-sensitive enable | 
display-name name 
virtual -url URL 



disable 
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where: 



cache -duration 


seconds 


Specifies the length of time in seconds that user and administrator 
credentials received from the SiteMinder policy server are cached. 
Credentials can be cached for up to 3932100 seconds. The default 
value is 9 0 0 seconds (15 minutes). 


case-sensitive 


enable | 
disable 


Specifies whether the SiteMinder policy server is configured to 
expect case-sensitive usernames and passwords. 


display-name 


name 


Equivalent to the display-name option in the CPL authenticate 
action. The default value for the display name is the realm name. 
The display name cannot be longer than 128 characters and it 
cannot be null. 


virtual-url 


URL 


The URL to redirect to when the user needs to be challenged for 
credentials. If the ProxySG is participating in SSO, the virtual 
hostname must be in the same cookie domain as the other servers 
participating in the SSO. It cannot be an IP address or the default, 
www . cf auth . com. 



Creating the CPL 

You can create CPL policies now that you have completed SiteMinder realm configuration. Be aware 
that the examples below are just part of a comprehensive authentication policy. By themselves, they 
are not adequate for your purposes. 

The examples below assume the default policy condition is nllozv. On new SGOS 4.x systems, the 
default policy condition is deny. 



Note: Refer to the Blue Coat ProxySG Content Policy Language Guide for details about CPL and 

how transactions trigger the evaluation of policy file <Proxy> and other layers. 



□ Every SiteMinder-authenticated user is allowed access the ProxySG. 

< Proxy > 

authenticate (SiteMinderRealm) 

□ Group membership is the determining factor in granting access to the ProxySG. 

< Proxy > 

authenticate (LDAPRealm) 

< Proxy > 

group="cn=proxyusers, ou=groups, o=myco" 
deny 
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Section I: Oracle COREid 

The ProxySG can be configured to consult an Oracle COREid (formerly known as Oracle NetPoint) 
Access Server for authentication and session management decisions. This requires that a COREid 
realm be configured on the ProxySG and policy written to use that realm for authentication. 

The ProxySG supports authentication with Oracle COREid v6.5 and v7.0. 

Access to the COREid Access System is done through the Blue Coat Authentication and Authorization 
Agent (BCAAA), which must be installed on a Windows 2000 system or higher with access to the 
COREid Access Servers. 

Understanding COREid Interaction with Blue Coat 

Within the COREid Access System, BCAAA acts as a custom AccessGate. It communicates with the 
COREid Access Servers to authenticate the user and to obtain a COREid session token, authorization 
actions, and group membership information. 

HTTP header variables and cookies specified as authorization actions are returned to BCAAA and 
forwarded to the SG appliance. They can (as an option) be included in requests forwarded by the 
appliance. 

Within the SG system, BCAAA acts as its agent to communicate with the COREid Access Servers. The 
SG appliance provides the user information to be validated to BCAAA, and receives the session token 
and other information from BCAAA. 

Each SG COREid realm used causes the creation of a BCAAA process on the Windows host computer 
running BCAAA. When a process is created, a temporary working directory containing the Oracle 
COREid files needed for configuration is created for that process. A single host computer can support 
multiple SG realms (from the same or different SG appliances); the number depends on the capacity of 
the BCAAA host computer and the amount of activity in the realms. 

Configuration of the SG COREid realm must be coordinated with configuration of the Access System. 
Each must be aware of the AccessGate. In addition, certain authorization actions must be configured 
in the Access System so that BCAAA gets the information the SG appliance needs. 

Configuring the COREid Access System 



Note: Blue Coat assumes you are familiar with the configuration of the COREid Access System 

and WebGates. 



Since BCAAA is an AccessGate in the COREid Access System, it must be configured in the Access 
System just like any other AccessGate. BCAAA obtains its configuration from the ProxySG so 
configuration of BCAAA on the host computer is not required. If the Cert Transport Security Mode is 
used by the Access System, then the certificate files for the BCAAA AccessGate must reside on 
BCAAA's host computer. 
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COREid protects resources identified by URLs in policy domains. A ProxySG COREid realm is 
associated with a single protected resource. This could be an already existing resource in the Access 
System, (typical for a reverse proxy arrangement) or it could be a resource created specifically to 
protect access to ProxySG services (typical for a forward proxy). 



Important: The request URL is not sent to the Access System as the requested resource; the 

requested resource is the entire ProxySG realm. Access control of individual URLs is 
done on the ProxySG using policy. 



The COREid policy domain that controls the protected resource must use one of the challenge 
methods supported by the ProxySG. 

Supported challenge methods are Basic, X.509 Certificates and Forms. Acquiring the credentials over 
SSL is supported as well as challenge redirects to another server. 

The ProxySG requires information about the authenticated user to be returned as COREid 
authorization actions for the associated protected resource. Since authentication actions are not 
returned when a session token is simply validated, the actions must be authorization and not 
authentication actions. 

The following authorization actions should be set for all three authorization types (Success, Failure, 
and Inconclusive): 

□ A Header Var action with the name BCSI_USERNAME and with the value corresponding to the 
simple username of the authenticated user. For example, with an LDAP directory this might be 
the value of the cn attribute or the uid attribute. 

□ A Header Var action with the name BCSl_GROUPS and the value corresponding to the list of groups 
to which the authenticated user belongs. For example, with an LDAP directory this might be the 
value of the memberOf attribute. 

Once the COREid AccessGate, authentication scheme, policy domain, rules, and actions have been 
defined, the ProxySG can be configured. 

Additional COREid Configuration Notes 

The ProxySG Appliance's credential cache only caches the user's authentication information for the 
lesser of the two values of the time-to-live (TTL) configured on the ProxySG and the session TTL 
configured in the Access System for the AccessGate. 

Configuring the ProxySG Realm 

The ProxySG realm must be configured so that it can: 

□ Communicate with the Blue Coat agent(s) that act on its behalf (hostname or IP address, port, SSL 
options, and the like). 

□ Provide BCAAA with the information necessary to allow it to identify itself as an AccessGate 
(AccessGate id, shared secret). 
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□ Provide BCAAA with the information that allows it to contact the primary COREid Access Server 
(IP address, port, connection information). 

□ Provide BCAAA with the information that it needs to do authentication and collect authorization 
information (protected resource name), and general options (off-box redirection). 

For more information on configuring the ProxySG COREid realm, see "Creating a COREid Realm" on 
page 437. 



Note: All ProxySG and agent configuration is done on the ProxySG. The ProxySG sends the 

necessary information to BCAAA when it establishes communication. 



Participating in a Single Sign-On (SSO) Scheme 

The ProxySG can participate in SSO using the encrypted ObSSOCookie cookie. This cookie is set in the 
browser by the first system in the domain that authenticates the user; other systems in the domain 
obtain authentication information from the cookie and so do not have to challenge the user for 
credentials. The ProxySG sets the ObSSOCookie cookie if it is the first system to authenticate a user, 
and authenticates the user based on the cookie if the cookie is present. 

Since the SSO information is carried in a cookie, the ProxySG must be in the same cookie domain as 
the servers participating in SSO. This imposes restrictions on the authenticate . mode ( ) used on the 
ProxySG. 

□ A reverse proxy can use any origin mode. 

□ A forward proxy must use one of the origin- redirect modes (such as 
origin-cookie-redirect). When using origin- * -redirect modes, the virtual URL's 
hostname must be in the same cookie domain as the other systems. It cannot be an IP address; the 
default www . cf auth . com does not work either. 

When using origin- * - redirect, the SSO cookie is automatically set in an appropriate response after 
the ProxySG authenticates the user. When using origin mode (in a reverse proxy), setting this cookie 
must be explicitly specified by the administrator using the policy substitution variable 
$ (x-agent-sso-cookie) . The variable $ (x-agent-sso-cookie) expands to the appropriate value 
of the set-cookie: header. 

Avoiding ProxySG Challenges 

In some COREid deployments all credential challenges are issued by a central authentication service. 
Protected services do not challenge and process request credentials; instead, they work entirely with 
the sso token. If the request does not include an sso token, or if the sso token is not acceptable, the 
request is redirected to the central service, where authentication occurs. Once authentication is 
complete, the request is redirected to the original resource with a response that sets the sso token. 
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If the COREid authentication scheme is configured to use a forms-based authentication, the ProxySG 
redirects authentication requests to the form URL automatically. If the authentication scheme is not 
using forms authentication but has specified a challenge redirect URL, the ProxySG only redirects the 
request to the central service if always-redirect-of fbox is enabled for the realm on the ProxySG. If 
the always-redirect-of fbox option is enabled, the authentication scheme must use forms 
authentication or have a challenge redirect URL specified. 



Note: The ProxySG must not attempt to authenticate a request for the off-box authentication 

URL. If necessary, authenticate (no) can be used in policy to prevent this. 



Creating a COREid Realm 

To Create a COREid Realm through the Management Console 
1. Select Configuration>Authentication>Oracle COREid>COREid Realms. 



COREid Realms | Agents | COREid Access Server | COREid Ge;' < 1 » 




2. Click New; the Add COREid Realm dialog displays. 



Add COREid Realm 



Realm name: 



Other realm configuration parameters have been set to default values. 

( OK ] [ Cancel J 

Figure 9-46: Adding the COREid Realm Name 

3. In the Realm name field, enter a realm name. The name can be 32 characters long and composed of 
alphanumeric characters and underscores. The name must start with a letter. The name should be 
meaningful to you, but it does not have to be the name of the COREid AccessGate. 

4. Click OK. 
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5. Click Apply. 

To Create a COREid Realm through the CLI 

At the (conf ig) prompt, enter the following command to create a COREid realm: 

SGOS# (config) security coreid create-realm realm_name 

where realm_name is the name of the COREid realm. 

Configuring Agents 

You must configure the COREid realm so that it can find the Blue Coat Authentication and 
Authorization Agent (BCAAA). 

1. Select Configuration>Authentication>Oracle COREid>Agents. 

COREid Realms Agents | COREid Access Server | COREid Gs[ < | ► 



ICOREidl 




- Alternate agent - 

Host: 

AccessGate id: 

- SSL Options — 

[~~1 Enable SSL 

Figure 9-47: Configuring COREid Agents 

2. Select the realm name to edit from the drop-down list. 

Note: You must have defined at least one COREid realm (using the COREid Realms tab) before 

attempting to configure COREid agents. If the message Realms must be added in the COREid 
Realms tab before editing this tab is displayed in red at the bottom of this page, you do not 
currently have any COREid realms defined. 

3. In the Primary agent section, enter the hostname or IP address where the agent resides. 

4. Change the port from the default of 16101 if necessary. 

5. Enter the AccessGate ID in the AccessGate id field. The AccessGate ID is the ID of the AccessGate 
as configured in the Access System. 

6. If an AccessGate password has been configured in the Access System, you must specify the 
password on the ProxySG. Click Change Secret and enter the password. The passwords can be up 
to 64 characters long and are always case sensitive. 

7. (Optional) Enter an alternate agent host and AccessGate ID in the Alternate agent section. 

8. (Optional) Select Enable SSL to enable SSL between the ProxySG and the BCAAA agent. 



Port: 16101 

| Change Secret | 
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9. (Optional) By default, if SSL is enabled, the COREid BCAAA certificate is verified. If you do not 
want to verify the agent certificate, disable this setting. 



To Edit a COREid Agent through the CLI 



1 . 



To define the primary and alternate agent configuration for the realm you just created, enter the 
following commands at the (conf ig) prompt: 



SGOS# (config) security coreid edit-realm realm_name 



SGOS#(config coreid realm_name ) 
SGOS# (config coreid realm_name) 
SGOS# (config coreid realm_name) 
SGOS# (config coreid realm_name) 
encrypt ed_shared_secret 
-or- 



primary-agent accessgate- id id 
primary-agent host host 
primary-agent port port 
primary-agent encrypted- secret 



SGOS# (config coreid realm_name ) 
SGOS# (config coreid realm_name ) 
SGOS# (config coreid realm_name ) 
SGOS# (config coreid realm_name ) 
SGOS# (config coreid realm_name) 
encrypt ed_shared_secret 
-or- 



primary-agent secret shared_secret 
alternate-agent accessgate- id id 
alternate-agent host host 
alternate-agent port port 
alternate-agent encrypted- secret 



SGOS# (config coreid realm_name ) alternate-agent secret shared_secret 



where 



primary- agent | 
alternate agent 




These commands allow you to configure either the 
primary or alternate agent for the COREid realm. 


accessgate-id 


id 


The ID of the AccessGate. 


host 


host 


The hostname or the IP address of the system that 
contains the agent. 


port 


port 


The port where the agent listens. 


encrypted- secret 
| secret 


shared secret 


The password (or encrypted password) associated with 
the primary or alternate AccessGate. (Passwords can be 
up to 64 characters long and are always case sensitive.) 
The primary use of the encrypted-secret command is to 
allow the ProxySG to reload a password that it 
encrypted. You can choose to use a third-party 
encryption application. The encrypted password is 
encrypted using RSA with OAEP padding, and is 
Base64 encoded with no newlines. 



2. To enable SSL between the ProxySG and the BCAAA agent and to have the BCAAA certificate 
verified, enter: 

SGOS# (config coreid realm_name) ssl enable 

SGOS# (config coreid realm_name ) ssl-verify-agent enable 
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Configuring the COREid Access Server 

Once you create a COREid realm, use the COREid Access Server page to specify the primary Access 
Server information. 

1. Select Configuration>Authentication>Oracle COREid>COREid Access Server. 



COREid Realms | Agents COREid Access Servei | COREid Ge; ' < | > 



Realm name: 

Protected resource name: 
Security mode: 

T ransport certificates path: 
|~~l Always redirect off-bo* 



Open v Change Transport Pass Phrase 



[v] Validate client IP address 



Cl Add header responses from servei 
Access Servei ID: 

Access Server hostname: Port: 6021 

Figure 9-48: Configuring the COREid Access Server 

2. Select the realm name to edit from the drop-down list. 



Note: You must have defined at least one COREid realm (using the COREid Realms tab) before 

attempting to configure COREid agents. If the message Realms must be added in the COREid 
Realms tab before editing this tab is displayed in red at the bottom of this page, you do not 
currently have any COREid realms defined. 



3. Enter the protected resource name. The protected resource name is the same as the resource name 
defined in the Access System policy domain. 

4. Select the Security Transport Mode for the AccessGate to use when communicating with the 
Access System. 

5. If Simple or Cert mode is used, specify the Transport Pass Phrase configured in the Access System. 
Click Change Transport Pass Phrase to set the pass phrase. 

6. If Cert mode is used, specify the location on the BCAAA host machine where the key, server and 
CA chain certificates reside. The certificate files must be named aaa_key . pem, aaa_cert . pem, and 
aaa_chain.pem, respectively. 

7. To force authentication challenges to always be redirected to an off-box URL, select Always redirect 
off-box. 

8. To enable validation of the client IP address in SSO cookies, select Validate client IP address. If the 
client IP address in the SSO cookie can be valid yet different from the current request client IP 
address because of downstream proxies or other devices, then deselect the Validate client IP address 
in the realm. Also modify the WebGates participating in SSO with the ProxySG. Modify the 
WebGateStatic . 1st file to either set the ipvalidation parameter to false or to add the downstream 
proxy/ device to the IPValidationExceptions lists. 
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9. If your Web applications need information from the Authorization Actions, select Add Header 
Responses. Authorization actions from the policy domain obtained during authentication are 
added to each request forwarded by the ProxySG. Header responses replace any existing header 
of the same name; if no such header exists, the header is added. Cookie responses replace a cookie 
header with the same cookie name, if no such cookie header exists, one is added. 

10. Specify the ID of the AccessGate's primary Access Server. 

11. Specify the hostname of the AccessGate's primary Access Server. 

12. Specify the port of the AccessGate's primary Access Server. 

13. Click Apply. 



To Edit a COREid Access Server through the CLI 



To create and edit the COREid Access Server configuration for the realm you just created, enter the 
following commands: 



SGOS# (config) security coreid edit-realm realm_name 

SGOS#(config coreid realm_name) protected-resource-name resource name 
SGOS# (config coreid realm_name) security-mode cert | open | simple 
SGOS# (config coreid realm_name) transport-pass-phrase pass_phrase 



-or- 

SGOS# (config coreid realm_name ) 
en cryp t e d_pa s s_phra s e 
SGOS# (config coreid realm_name ) 
SGOS# (config coreid realm_name ) 
SGOS# (config coreid realm_name ) 
SGOS# (config coreid realm_name ) 
SGOS# (config coreid realm_name) 
SGOS# (config coreid realm_name) 
SGOS# (config coreid realm_name) 



encrypted- transport -pass -phrase 

certificate-path certificate path 
always-redirect-of fbox disable | enable 
validate-client-IP disable | enable 
add-header-responses disable | enable 
access-server-id id 
access - server-hostname hostname 
access - server-port port 



where: 



protected-resource- 

name 


protected resource 
name 


The resource name defined in the 
Access System policy domain. 


security-mode 


cert | open | simple 


The Security Transport Mode for the 
AccessGate to use when 
communicating with the Access 
System 


transport -pass -phrase 
-or- 

encrypt ed- transport - 
pass-phrase 


pass_phrase 

-or- 

encrypted pass phrase 


If Simple or Cert mode is used, the 
Transport passphrase (or encrypted 
passphrase) configured in the Access 
System. 



441 



Blue Coat ProxySG Configuration and Management Guide 



Section I: Oracle COREid 



certificate -path 


certificate path 


If Cert mode is used, the location on 
the BCAAA host machine where the 
key, server and CA chain certificates 
reside. The certificate files must be 
named aaa key . pem, 
aaa cert . pem, and 
aaa chain . pem, respectively. 


always -redirect -off box 


disable | enable 


Forces authentication challenges to 
always be redirected to an off -box 
URL. 


validate-client-IP 


disable | enable 


Enables validation of the client IP 
address in SSO cookies. If the client IP 
address in the SSO cookie can be valid 
yet different from the current request 
client IP address because of 
downstream proxies or other devices, 
then disable client IP address 
validation. Also, modify the 
WebGates participating in SSO with 
the ProxySG. Modify the 
WebGateStatic . 1st file to either 
set the ipvalidation parameter to false 
or to add the downstream 
proxy/device to the 
IPValidationExceptions lists. 


add-header- responses 


disable | enable 


When enabled, authorization actions 
from the policy domain obtained 
during authentication are added to 
each request forwarded by the 
ProxySG. Header responses replace 
any existing header of the same name; 
if no such header exists, the header is 
added. Cookie responses replace a 
cookie header with the same cookie 
name; if no such cookie header exists, 
one is added. 


access -server- id 


id 


The ID of the primary Access Server. 


access -server- hostname 


hostname 


The hostname of the primary Access 
Server. 


access -server-port 


port 


The port of the primary Access Server. 



Configuring the General COREid Settings 

The COREid General tab allows you to set a display name, cache credentials timeout, request timeout 
value, and case-sensitivity and create a virtual URL. 
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To Manage General Settings for the COREid Realm through the Management Console 

1. Select Authentication>Oracle COREid>COREid General. 



aEid Realms | Agents 



COREid Access Server 



COREid General 




Realm name: 



COREidl 



Display name: [ COREidl 



Timeout request after 60 I seconds 



Cache credentials 900 I seconds 




| | Case sensitive 



Figure 9-49: Configuring COREid General Properties 

2. From the Realm Name drop-down list, select the COREid realm for which you want to change 
properties. 



Note: You must have defined at least one COREid realm (using the COREid Realms tab) before 

attempting to configure COREid agents. If the message Realms must be added in the COREid 
Realms tab before editing this tab is displayed in red at the bottom of this page, you do not 
currently have any COREid realms defined. 



3. If needed, change the COREid realm display name. The default value for the display name is the 
realm name. The display name cannot be longer than 128 characters and it cannot be null. 

4. Specify the length of time, in seconds, to elapse before timeout if a response from BCAAA is not 
received. 

5. Specify the length of time, in seconds, that user and administrator credentials are cached. 
Credentials can be cached for up to 3932100 seconds. The default cache-duration is 900 seconds 
(15 minutes). 

6. If you want username and group comparisons on the ProxySG to be case sensitive, select Case 
sensitive. 

7. Specify the virtual URL to redirect the user to when they need to be challenged by the ProxySG. If 
the ProxySG is participating in SSO, the virtual hostname must be in the same cookie domain as 
the other servers participating in the SSO. It cannot be an IP address or the default, 

www . cf auth . com. 

8. Click Apply. 

To Set COREid General Settings through the CLI 

At the (conf ig) command prompt, enter the following commands to configure general settings: 
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SGOS# (config coreid realm_name ) display-name name 

SGOS#(config coreid realm_name ) timeout seconds 

SGOS# (config coreid realm_name) cache-duration seconds 

SGOS# (config coreid realm_name ) case-sensitive disable | enable 

SGOS# (config coreid realm_name) virtual-url URL 



where: 



display-name 


name 


Equivalent to the display-name option in the CPL authenticate 
action. The default value for the display name is the realm name. 
The display name cannot be longer than 128 characters and it 
cannot be null. 


timeout 


seconds 


Specifies the length of time, in seconds, to elapse before timeout 
if a response from BCAAA is not received. 


cache -duration 


seconds 


Specifies the length of time in seconds that user and administrator 
credentials received are cached. Credentials can be cached for up 
to 3932100 seconds. The default value is 90 0 seconds (15 
minutes). 


case-sensitive 


disable 
| enable 


Specifies whether the username and group comparisons on the 
ProxySG should be case-sensitive. 


virtual-url 


URL 


The URL to redirect to when the user needs to be challenged for 
credentials. If the ProxySG is participating in SSO, the virtual 
hostname must be in the same cookie domain as the other servers 
participating in the SSO. It cannot be an IP address or the default, 
www . cf auth . com. 



Creating the CPL 

You can create CPL policies now that you have completed COREid realm configuration. Be aware that 
the examples below are just part of a comprehensive authentication policy. By themselves, they are not 
adequate for your purposes. 

The examples below assume the default policy condition is allow. On new SGOS 4.x systems, the 
default policy condition is deny. 



Note: Refer to the Bine Coat ProxySG Content Policy Language Guide for details about CPL and 

how transactions trigger the evaluation of policy file < Proxy > and other layers. 



□ Every COREid-authenticated user is allowed access the ProxySG. 

< Proxy > 

authenticate (COREidRealm) 

□ Group membership is the determining factor in granting access to the ProxySG. 

< Proxy > 

authenticate (COREidRealm) 
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< Proxy > 

group=" cn=proxyusers , ou=groups , 
deny 



o=myco" 
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Section J: Using XML Realms 

If you use an authentication or authorization protocol that is not natively supported by Blue Coat, you 
can use the XML realm to integrate SGOS with the authentication/ authorization protocol. 

This section includes the following topics: 

□ "About XML Realms" 

□ "Before Creating an XML Realm" on page 447 

□ "Creating an XML Realm" on page 447 

□ "Configuring XML Servers" on page 448 

□ "Configuring XML Options" on page 449 

□ "Configuring XML Realm Authorization" on page 450 

□ "Configuring XML General Realm Properties" on page 451 

□ "Creating the CPL" on page 452 

□ "Viewing Statistics" on page 452 

About XML Realms 

An XML realm uses XML messages to request authentication and authorization information from an 
HTTP XML service (the XML responder that runs on an external server). The XML realm (the XML 
requestor) supports both HTTP GET and HTTP POST methods to request an XML response. The XML 
messages are based on SOAP 1.2. 

The XML responder service accepts XML requests from the ProxySG, communicates with an 
authentication or authorization server, and responds with the result. When the realm is used to 
authenticate users, it challenges for Basic credentials. The username and password are then sent to the 
XML responder to authenticate and authorize the user. 

The XML realm can place the username and password in the HTTP headers of the request or in the 
body of the XML POST request. If the credentials are placed in the HTTP headers, the Web server 
must do the authentication and the XML service just handles authorization. If credentials are placed in 
the XML request body, the XML service handles both authentication and authorization. 

XML messages must conform to the Blue Coat XML realm schema. This is an XML schema based on 
SOAP 1.2. The schema can be found at http://www.bluecoat.com/ xmlns/xml-realm/1.0. 

An authenticate request sends the credentials to the XML responder and optionally sends the groups 
and attributes referenced in policy. The XML responder can then authenticate the credentials. The 
response indicates if the user was successfully authenticated and also includes the user 's groups and 
attributes if the XML responder is doing authorization. 

An authorize request sends the authenticated username to the XML responder and optionally sends 
the groups and attributes referenced in policy. The response includes the user's groups and attributes. 
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Before Creating an XML Realm 

The following list describes the tasks you must complete before creating an XML realm. 

□ Create an appropriate XML realm responder (one that is designed to talk to the Blue Coat XML 
realm protocol) and install it on an HTTP Web server. You can either create the responder yourself 
or have a third party create it, such as Blue Coat Professional Services. 

To create the XML realm responder, see Appendix G: "XML Protocol" on page 1147 for a 
description of the SOAP protocol. The XML responder must correctly conform to the protocol. 
The XML realm performance is dependent on the response time of the XML responder. 

□ Configure an HTTP server with appropriate authentication controls. The authentication service 
can either depend on the HTTP server to authenticate the credentials, or the service can 
authenticate them directly. If the HTTP server is used to authenticate the credentials, it must be set 
up to protect the service with HTTP Basic authentication. 

□ (Optional) Configure an alternate HTTP server for redundancy. The XML responder service must 
be installed on the alternate server. 

Creating an XML Realm 

To create an XML realm: 

Before you create an XML realm, be sure to complete the tasks in "Before Creating an XML 
Realm"above. 

1. In the Management Console, select Configuration > Authentication > XML > XML Realms. 

2. Click New. 



XML Realms | XML Servers j XML Options j Authorization j XML General 

- XML Realms 

Names 



XML_1 




Figure 9-50: Adding an XML Realm 
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3. In the Realm name field, enter a realm name. The name can be 32 characters long, composed of 
alphanumeric characters and underscores. The name must start with a letter. 

4. Click OK. 

1. Click Apply to commit the changes to the SG appliance. 

Configuring XML Servers 



Note: You do not need to change these values if the default settings are acceptable. 



After you have created an XML realm, go to the XML Servers page to change current default settings. 

To configure XML server properties: 

1. In the Management Console, select Configuration > Authentication > XML > XML Servers. 




Figure 9-51 : Configuring XML Servers 

2. From the Realm Name drop-down list, select the XML realm. 

3. Select the Responder options, as follows: 

a. Responder: Select the XML responder service to configure — Primary or Alternate — from the 
drop-down list. Primary is the default. You can configure both responder services before 
clicking Apply. 

b. Host: This is the hostname or IP address of the HTTP server that has the XML service. You 
must specify a host. The port defaults to port 80. 

c. Authenticate request path: Enter the XML responder path for authentication requests. 

d. Authorize request path: Enter the XML responder path for authorization requests. 

4. In the timeout request field, enter the number of seconds for the system to wait for a request. 



448 




Blue Coat ProxySG Configuration and Management Guide 



Section J: Using XML Realms 

5. Enter the number of times for the system to retry a request. The default is not to retry a request. 

6. Specify the maximum number of connections to the responder. The default is five connections. 

7. Select the One-time passwords check box to use one-time passwords. This allows you to integrate 
with a non-Blue Coat supported authentication service that uses one-time passwords. 



Note: One-time passwords are passwords that become invalid as soon as they are used. The 

passwords are often generated by a token or program, although pre-printed lists are also 
used. Using one-time passwords ensures that the password cannot be used in a replay 
attack. 



2. Click Apply to commit the changes to the SG appliance. 

8. Repeat the above steps for additional XML realms, up to a total of 40. 

Configuring XML Options 

Note: You do not need to change these values if the default settings are acceptable. 



With XML realms, you can place the username and password in the HTTP headers of the request or in 
the body of the XML POST request. If the credentials are placed in the HTTP headers, the Web server 
can do the authentication and the XML service can just handle authorization. If the credentials are 
placed in the XML request body, the XML service handles both authentication and authorization. 

To configure XML options: 

1. In the Management Console, select Configuration > Authentication > XML > XML Options. 



XML Realms | XML Servers XML Options | Authorization 


XML General 




Realm name: xm n 




V 


User credential location: 

® Put user credentials for authentication in the HTTP header 
O Put user credentials for authentication in the request 






Username parameter: username 







Figure 9-52: Configuring XML Options 

2. From the Realm Name drop-down list, select the XML realm. 

3. Select one of the radio buttons to determine where to place the user credentials. 

• If the HTTP server is integrated with the authentication system, the HTTP server can 

authenticate the credentials. Select the Put user credentials for authentication in the HTTP header 
radio button. However, if this does not provide enough flexibility, the XML responder can do 
authentication. 
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• To have the XML responder service handle both authentication and authorization, select the 
Put user credentials for authentication in the request radio button. 

4. Enter the username parameter in the Username parameter field. The default is username. 

3. Click Apply to commit the changes to the SG appliance. 

Configuring XML Realm Authorization 

Note: You do not need to change these values if the default settings are acceptable. 



After you have created the XML realm, you still must take into consideration how you will use 
authentication and authorization: 

□ Use an XML realm for both authorization and authentication. 

The realm is used for authentication and uses itself for authorization. 

□ Use an XML realm for authentication another realm for authorization. 

Am XML realm can be used for authentication and use another realm for authorization. The 
authorization realm can be a Local realm, an LDAP realm or another XML realm. 

□ Use an XML realm as an authorization realm for another realm. 

Am XML realm can be used as an authorization realm for another realm that is doing 
authentication. The authentication realm can be a Certificate realm, a Policy Substitution realm, a 
Novell SSO realm, a Windows SSO realm or another XML realm. 

In all cases, you must write policy to authenticate and authorize the users. For information on writing 
policy for an XML realm, see <LI Link text>"Creating the CPL" on page 452. 

To configure XML authorization properties: 

1. In the Management Console, select Configuration > Authentication > XML > Authorization. 




2. From the Realm name drop-down list, select the XML realm. 
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a. Authorization realm name: If the XML realm is not doing authorization, select an 

authorization realm from the drop-down list. By default, the authorization realm name is 
Self. 



Note: If Self is selected, the Authorization realm name drop-down list is unavailable. To 

make the Authorization realm name drop-down list active, clear the Self check box. 

b. Authorization username: The default is Use full username. Clear the Use full username check 
box to use a different name or to use a policy substitution that generates a username. 

c. Default group: The default is no groups are selected. 

d. The send the groups and attributes of interest in the request check box is selected by default. 
These are the groups and attributes that are used in policy. 

4. Click Apply to commit the changes to the SG appliance. 

Configuring XML General Realm Properties 

The XML General page allows you to indicate the length of time that credentials are cached for a 
specific realm, the realm's display name, and if you want to use a special virtual URL for this realm. 

To configure general XML settings: 

1. In the Management Console, select Configuration > Authentication > XML > XML General. 




Figure 9-54: Configuring General XML Properties 
2. From the Realm Name drop-down list, select the XML realm. 

a. The default value for the Display name is the realm name. You can change it. The display 
name cannot exceed 128 characters and it cannot be empty. 

b. In the Cache credentials field, specify the length of time in seconds that user and 
administrator credentials received from the XML server are cached. Credentials can be 
cached for up to 3932100 seconds. The default value is 900 seconds (15 minutes). 

c. You can enter a virtual URL based on the individual realm. For information on the virtual 
URL, see Chapter 8: "Security and Authentication" on page 309. 

5. Click Apply to commit the changes to the SG appliance. 
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Related CLI Syntax to Configure an XML Realm 

□ To enter configuration mode for the service: 

SGOS# (config) security create xml realm_name 
SGOS# (config) security edit xml realm_name 

The following subcommands are available: 

SGOS# (config realm_name ) ? 

SGOS# (config realm_name ) alternate-responder {host host | path {authenticate 

authenticate-path | authorize authorize-path} | port port} 

SGOS# (config realm_name ) authorization {default-group-name group_name | realm 
{none ] realm-name realm_name | self} | username {use- full -username | username}} 

SGOS# (config realm_name ) cache-duration seconds 
SGOS# (config realm_name ) connections number 
SGOS# (config realm_name ) display-name display_name 
SGOS# (config realm_name ) exit 

SGOS# (config realm_name ) no {alternate-responder | default -group -name} 

SGOS# (config realm_name ) one-time-passwords {enable | disable} 

SGOS# (config realm_name ) primary- responder {host host | path {authenticate 

authenticate-path | authorize authorize-path } | port port} 

SGOS# (config realm_name ) rename new_realm_name 
SGOS# (config realm_name ) retry number 
SGOS# (config realm_name ) timeout seconds 
SGOS# (config realm_name ) view 

SGOS# (config realm_name ) virtual-url virtual_url 

SGOS# (config realm_name) xml {credential {header [ request} | request- interested 
{enable | disable} | username username parameter} 

Creating the CPL 

This CPL example gives access to users who are authenticated in the XML realm called eng_users and 
who are in the group Waterloo. You also can create policy for XML realms through VPM. 



Note: For information on using policy, see Chapter 14: "The Visual Policy Manager" on 

page 567 or refer to the Blue Coat ProxySG Content Policy Language Guide. 



<proxy> 

authenticate (eng_users) 

<proxy> 

realm=eng_users group=waterloo allow 

Viewing Statistics 

To view statistics for XML realms, click Statistics > Advanced. Select one of the advanced links. 
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Section K: Policy Substitution Realm 

A Policy Substitution realm provides a mechanism for identifying and authorizing users based on 
information in the request to the SG appliance. The realm uses information in the request and about 
the client to identify the user. The realm is configured to construct user identity information by using 
policy substitutions. 

If authorization data (such as group membership) is needed, the realm can be configured with the 
name of an associated authorization realm (such as LDAP or local). If an authorization realm is 
configured, the fully-qualified username is sent to the authorization realm's authority to collect 
authorization data. 

You can use policy substitutions realms in many situations. For example, a Policy Substitution realm 
can be configured to identify the user: 

□ based on the results of a NetBIOS over TCP/IP query to the client computer. 

□ based on the results of a reverse DNS lookup of the client computer's IP address. 

□ based on the contents of a header in the request. This might be used when a downstream device is 
authenticating the user. 

□ based on the results of an Ident query to the client computer. 

The Policy Substitution realm is used typically for best-effort user discovery, mainly for logging and 
subsequent reporting purposes, without the need to authenticate the user. Be aware that if you use 
Policy Substitution realms to provide granular policy on a user, it might not be very secure because 
the information used to identify the user can be forged. 

This section discusses the following topics: 

□ "How Policy Substitution Realms Work" 

□ "Creating a Policy Substitution Realm" 

□ "Configuring User Information" 

□ "Creating a List of Users to Ignore" 

□ "Configuring Authorization" 

□ "Defining Policy Substitution Realm General Properties" 

How Policy Substitution Realms Work 

The realm is configured the same way as other realms, except that the realm uses policy substitutions 
to construct the username and full username from information available in and about the request. 
Any policy substitution whose value is available at client logon can be used to provide information for 
the name. 

The Policy Substitution realm, in addition to allowing you to create and manipulate realm properties, 
such as the name of the realm and the number of seconds that credential cache entries from this realm 
are valid, also contains attributes to determine the user's identity. The user's identity can be 
determined by explicitly defining the usernames or by searching a LDAP server. The following two 
fields are used to determine the user's identity by definition: 
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□ A user field: A string containing policy substitutions that describes how to construct the simple 
username. 

□ A full username field: A string containing policy substitutions that describes how to construct the 
full username, which is used for authorization realm lookups. This can either be an LDAP FQDN 
when the authorization realm is an LDAP realm, or a simple name when local realms are being 
used for authorization. 



Note: The user field and username field must include at least one substitution that successfully 

evaluates in order for the user to be considered authenticated. 



If no policy substitutions exist that map directly to the user's simple and full usernames but there are 
substitutions that map to attributes on the user on the LDAP server, the user's identity can be 
determined by searching the LDAP server. The following fields are used to determine the user's 
identity by LDAP search: 

□ LDAP search realm: The LDAP realm on the ProxySG that corresponds to the LDAP server where 
the user resides 

□ Search filter: An LDAP search filter as defined in RFC 2254 to be used in the LDAP search 
operation. Similar to the explicitly defined username and full username fields, the search filter 
string can contain policy substitutions that are available based on the user's request. The search 
filter string must be escaped according to RFC 2254. The policy substitution modifier 
escape_ldap_f ilter is recommended to use with any policy substitutions that could contain 
characters that need to be escaped. It will escape the policy substitution value per RFC 2254. 



Note: The search filter must include at least one substitution that successfully evaluates before 

the LDAP search will be issued and the user authenticated. 



□ User attribute: The attribute on the search result entry that corresponds to the user's full 

username. If the search result entry is a user entry, the attribute is usually the FQDN of that entry. 
The user's full username is the value of the specified attribute. If the attribute value is an FQDN, 
the user's simple username is the value of the first attribute in the FQDN. If the attribute value is 
not an FQDN, the simple username is the same as the full username. 



Note: Policy Substitution realms never challenge for credentials. If the username and full 

username cannot be determined from the configured substitutions, authentication in the 
Policy Substitution realm fails. 



Remember that Policy Substitution realms do not require an authorization realm. If no authorization 
realm is configured, the user is not a member of any group. The effect this has on the user depends on 
the authorization policy. If the policy does not make any decisions based on groups, you do not need 
to specify an authorization realm. Also, if your policy is such that it works as desired when all Policy 
Substitution realm users are not in any group, you do not have to specify an authorization realm. 
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Once the Policy Substitution realm is configured, you must create policy to authenticate the user. 



Note: If all the policy substitutions fail, authentication fails. If any policy substitution works, 

authentication succeeds in the realm. 



Example 

The following is an example of how to use substitutions with Policy Substitution realms. 

Assumptions: 

n The user susie. smith is logged in to a Windows client computer at IP address 10.25.36.47. 

□ The Windows messenger service is enabled on the client computer. 

□ The client computer is in the domain AUTHTEAM. 

□ The customer has an LDAP directory in which group information is stored. The DN for a user's 
group information is 

cn=u sername , cn=users , dc =computer_domain , dc = company, dc = com 

where username is the name of the user, and computer_domain is the domain to which 
the user's computer belongs. 

□ A login script that runs on the client computer updates a DNS server so that a reverse DNS 
lookup for 10.25.36.47 results in susie . smith . authteam . location . company . com. 

Results: 

Under these circumstances, the following username and full username attributes might be used: 

□ Username: $ (netbios . messenger -username) @$ (client . address ) . 

This results in SUSIE . SMITH@10 . 25 . 36 . 47. 

□ Full username: cn=$ (netbios .messenger-username) ,cn=users, 
dc=$ (netbios . computer-domain) , dc=company, dc=com. 

This results in cn=SUSIE . SMITH, cn=users , dc=AUTHTEAM, dc=company, dc = com. 

□ Username: $ (netbios . computer-domain) \$ (netbios .messenger-username) . 

This results in authteam \ susie . smith. 

□ Username: $ (client . host : label ( 6 ) ) . $ (client . host : label ( 5 ) ) . 

This results in susie . smith. 

Example 

The following is an example of how to determine the user's identity by search. 
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Assumptions: 

• The user susie. smith is logged in to a Windows client computer. 

• The customer has an LDAP directory in which group information is stored. The FQDN for 
Susie Smith is ”cn=Susie Smith, cn=Users, dc=Eng, dc=company, dc=com". 

Results: 

Under these circumstances the login username can not be explicitly mapped to the user's FQDN, so a 
search of the LDAP server for the user's login identity is required instead. The following values can be 
used: 



• Search filter: (sAMAccountName=$(netbios.messenger-username:escape_ldap_filter)) 

• User attribute: default of FQDN 

This results in a simple username of "Susie Smith” and a full username of ”cn=Susie Smith, 
cn=Users, dc=Eng, dc=company, dc=com". 

Creating a Policy Substitution Realm 

To Create a Policy Substitution Realm through the Management Console 
1. Select Configuration>Authentication>Policy Substitution>Policy Substitution Realms. 
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Policy Substitution Realms | User Information | Ignore Users | Authorization j General 

- Policy Substitution Realms 

Names 



PS_1 










1 


New 


i r 



Figure 9-55: Policy Substitution Realms Tab 

2. Click New; the Add Policy Substitution Realm dialog displays. 

3. In the Realm name field, enter a realm name. The name can be up to 32 characters long and 
composed of alphanumeric characters and underscores. The name must start with a letter. 

4. Click OK; click Apply. 

To Create a Policy Substitution Realm through the CLI: 

Up to 40 Policy Substitution realms can be configured per ProxySG. 

At the (conf ig) command prompt, enter the following command to create a Policy Substitution 
realm: 

SGOS# (config) security policy- substitution create-realm realm_name 
where realm_name is the name of the new Policy Substitution realm. 
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Configuring User Information 

To Define Policy Substitution User Information through the Management Console 

1. Select Configuration>Authentication>Policy Substitution>User Information. 

Policy Substitution Realms User Information j Ignore Users | Authorization | General 



Realm name: 



PS 1 



O Determine username by definition 
Username: 



Full username: 



0 Determine username by search 



LDAP search realm name: 



LDAP 1 



Search filter: 



User attribute: ^ F q DN 

Figure 9-56: Policy Substitution User Information Tab 

2. From the Realm Name drop-down list, select the Policy Substitution realm for which you want to 
change realm properties. 



Note: You must have defined at least one Policy Substitution realm (using the Policy 

Substitution Realms tab) before attempting to set Policy Substitution realm properties. If 
the message Realms must be added in the Policy Substitutions Realms tab 
before editing this tab is displayed in red at the bottom of this page, you do not 
currently have any Policy Substitution realms defined. 



3. Choose whether to determine username by definition or to determine username by search. 

• To determine username by definition: Select the Determine username by definition checkbox and 
specify the username and full username strings. Remember that the Username and Full 
username attributes are character strings that contain policy substitutions. When 
authentication is required for the transaction, these character strings are processed by the 
policy substitution mechanism, using the current transaction as input. The resulting string 
becomes the user's identity for the current transaction. For an overview of usernames and full 
usernames, see "How Policy Substitution Realms Work" on page 453. 

• To determine username by search, select the Determine username by search checkbox: 

• From the drop-down list, select the LDAP realm to use as a search realm. 

• The search filter must be a valid LDAP search filter per RFC 2254. The search filter can 
contain any of the policy substitutions that are available based on the user's request (such 
as IP address, netbios query result, and ident query result). 
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• The user attribute is the attribute on the LDAP search result that corresponds to the user's 
full username. The LDAP search usually results in user entries being returned, in which 
case the user attribute is the FQDN. If the LDAP search was for a non-user object, 
however, the username might be a different attribute on the search result entry. 

4. Click Apply. 



To Define Policy Substitution User Information through the CLI: 

1. Enter the policy substitution realm edit mode: 

SG0S# (config) security policy- substitution edit-realm realm_name 

This changes the prompt to 

SG0S# (config policy-substitution realm_name ) 

2. To search by definition, enter the following commands: 

SGOS# (config policy-substitution realm_name) identification determine-usernames 
by -definition 

SGOS# (config policy-substitution realm_name) identification username 
const rue tion_rule 

SGOS# (config policy-substitution realm_name ) identification full-username 
construction rule 



where 



username 



construction_ The username as created through policy 
rule substitutions. The construction rule is made up 

any of the substitutions whose values are 
available at client logon, listed in Appendix D, 
"CPL Substitutions," in the Blue Coat ProxySG 
Content Policy Language Guide. 

Note: The username and full-username 
attributes are character strings that contain 
policy substitutions. When authentication is 
required for the transaction, these character 
strings are processed by the policy 
substitution mechanism, using the current 
transaction as input. The resulting string is 
stored in the user object in the transaction, 
and becomes the user's identity. 

To create usernames for various uses in Policy 
Substitution realms, see the Blue Coat ProxySG 
Content Policy Language Guide. 
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full -username 



construction_ The full username as created through policy 
rule substitutions. The construction rule is made up 

any of the policy substitutions whose values are 
available at client logon listed in Appendix D, 
"CPL Substitutions," in the Blue Coat ProxySG 
Content Policy Language Guide. 

Note: The username and full-username 
attributes are character strings that contain 
policy substitutions. When authentication is 
required for the transaction, these character 
strings are processed by the policy 
substitution mechanism, using the current 
transaction as input. The resulting string is 
stored in the user object in the transaction, 
and becomes the user's identity. 

To create full usernames for the various uses of 
Policy Substitution realms, see the Blue Coat 
ProxySG Content Policy Language Guide. 



3. To determine users by search, enter the following commands: 

SGOS# (config policy-substitution realm_name) identification determine-usernames 
by-search 

SGOS# (config policy-substitution realm_name ) identification realm-name 
LDAP_realm 

SGOS# (config policy-substitution realm_name) identification search- filter 
search_f ilter 

SGOS# (config policy-substitution realm_name ) identification user-attribute {fqdn 
| LDAP_attribute_name } 

where 



realm-name 


LDAP realm 


Specifies the LDAP realm to search. 


search- filter 


search filter 


Specifies the search filter to use. The 
search filter must be a valid LDAP 
search filter per RFC 2254, and can 
contain policy substitutions that are 
available based on the user's request. 
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user- attribute 


(fqdn | 


The user attribute is the attribute on 




LDAP attribute name) 


the LDAP search result that 






corresponds to the user's full 
username. The LDAP search usually 
results in user entries being 
returned, in which case the user 
attribute is the FQDN. If the LDAP 
search was for a non-user object, 
however, the username might be a 
different attribute on the search 






result entry. 



Creating a List of Users to Ignore 

The Ignore Users tab is used to create a list of users to be ignored during an LDAP username search 
(see "Configuring User Information" on page 458). 



1. Select Configuration>Authentication>Policy Substitution>lgnore Users. 

Policy Substitution Realms | User Information Ignore Users j Authorization | General 

Realm name: ps_i v 

• Users to ignore 

Username 




[ New J Edit | | Delete 

Figure 9-57: The Ignore Users Tab 

2. From the Realm Name drop-down list, select the Policy Substitution realm for which you want to 
change realm properties. 
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Note: You must have defined at least one Policy Substitution realm (using the Policy 

Substitution Realms tab) before attempting to set Policy Substitution realm properties. If 
the message Realms must be added in the Policy Substitutions Realms tab 
before editing this tab is displayed in red at the bottom of this page, you do not 
currently have any Policy Substitution realms defined. 



3. Click New to add a username to be ignored during the username search. The username format 
depends on what the LDAP search is looking for but will most often be an LDAP FQDN. 

4. Click OK; repeat the previous step to add other users. 

5. Click Apply when done. 

Creating a List of Users to Ignore through the CLI: 

Enter the following commands: 

SGOS# (config policy-substitution realm_name ) identification determine-usernames 
by-search 

SGOS# (config policy-substitution realm_name) identification ignore-user-list 
(add username | clear | remove username } 

where add allows you to add a user to the list, clear removes all users from the list, and remove 
deletes one user from the list. 



Configuring Authorization 

Policy Substitution realms do not require an authorization realm. If the policy does not make any 
decisions based on groups, you need not specify an authorization realm. 



To configure an authorization realm through the Management Console: 
1. Select Configuration>Authentication>Policy Substitution>Authorization 



Policy Substitution Realms 



User Information 



Ignore Users 



Authorization 



General 



Realm name: p 5 j 



Authorization realm name: 



LDAP_1 



v 



Figure 9-58: The Authorization Tab 

2. From the Realm Name drop-down list, select the Policy Substitution realm for which you want to 
change realm properties. 
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Note: You must have defined at least one Policy Substitution realm (using the Policy 

Substitution Realms tab) before attempting to set Policy Substitution realm properties. If 
the message Realms must be added in the Policy Substitutions Realms tab 
before editing this tab is displayed in red at the bottom of this page, you do not 
currently have any Policy Substitution realms defined. 



3. From the Authorization Realm Name drop-down list, select the authorization realm you want to use 
to authorize users. 

4. Click Apply. 

To configure an authorization realm through the CLI: 

SGOS# (config) security policy- substitution edit-realm realm_name 
SGOS# (config policy-substitution realm_name ) authorization-realm-name 
authorization realm name 



Defining Policy Substitution Realm General Properties 

The Policy Substitution General tab allows you to specify the cache credentials duration and a virtual 
URL. 

To Configure Policy Substitution Realm General Settings through the Management Console 

1. Select Configuration>Authentication>Policy Substitution>General. 

Policy Substitution Realms ] User Information | Ignore Users | Authorization General 

Realm name: ps j 

Cache credentials 900 seconds 

r Virtual URL 

URL: 

Figure 9-59: Policy Substitution General Tab 

2. From the Realm name drop-down list, select the Policy Substitution realm for which to change 
properties. 



Note: You must have defined at least one Policy Substitution realm (using the Policy 

Substitution Realms tab) before attempting to set Policy Substitution general properties. If 
the message Realms must be added in the Policy Substitution Realms tab 
before editing this tab is displayed in red at the bottom of this page, you do not 
currently have any Policy Substitution realms defined. 



3. Specify the length of time, in seconds, that user and administrator credentials are cached. 

Credentials can be cached for up to 3932100 seconds. The default cache-duration is 900 seconds 
(15 minutes). 
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4. You can specify a virtual URL. For more information on the virtual URL, see "Understanding 
Origin-Style Redirection" on page 326. 

5. Click Apply. 



To Configure Policy Substitution Realm General Settings through the CLI 

1. Enter the following commands to modify Policy Substitution realm properties: 

SGOS# (config) security policy- substitution edit-realm realm_name 
SG0S# (config policy-substitution realm_name ) cache-duration seconds 
SGOS# (config policy-substitution realm_name) virtual-url URL 



where: 



cache -duration 


seconds 


The number of seconds that user and administrator 
credentials received from the Policy Substitution realm 
should be cached. The default is 90 0 seconds (15 minutes). 


virtual-url 


URL 


The authentication virtual URL for this Policy Substitution 
realm. 



2 . 



(Optional) View the results: 

SGOS# (config Policy Substitution realm_name ) view 



Realm name : PS_1 
Identification type: By Search 

Username : $ (netbios .messenger-user-name) 

Full username: cn=$ (netbios . messenger-user-name) , cn=users , 

dc=$ (netbios . computer-domain) 

Search realm: LDAP_1 

Search filter: ( sAMAccountName=$ (netbios . messenger-username : 

escape_ldap_f ilter) ) 



User attribute : 

Users to ignore : 
Authorization realm: 
Cache duration: 
Virtual URL: 



Entry FQDN 

cn=Service User, cn=Users, dc=company, dc=com 
LDAP_1 
600 



Notes 

□ Following are examples of how to configure four different types of Policy Substitution realms. For 
a list of available substitutions, see "Fields Available for Creating Access Log Formats" on 
page 1048. 

• Identity to be determined by sending a NetBIOS over TCP /IP query to the client computer, 
and using LDAP authorization 

SGOS# (config) security policy- substitution create-realm netbios 
SGOS# (config) security policy- substitution edit-realm netbios 
SGOS# (config policy-substitution netbios) username \ 

$ (netbios .messenger-username) 

SGOS# (config policy-substitution netbios) full -username \ 

cn=$ (netbios . messenger-username) , cn=users , dc=company, dc=com 

SGOS# (config policy-substitution netbios) authorization-realm-name ldap 
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• Identity to be determined by reverse DNS, using local authorization. Blue Coat assumes login 
scripts on the client computer update the DNS record for the client. 

SG0S# (config) security policy- substitution create-realm RDNS 
SG0S# (conf ig) security policy- substitution edit-realm RDNS 

SG0S# (config policy-substitution RDNS) username \ 

$ (client . host : label (5) ) . $ (client .host : label ( 6) ) 

#SGOS# (conf ig policy-substitution RDNS) full -username \ 

$ (client . host : label (5) ) . $ (client .host : label ( 6) ) 

SGOS# (config policy-substitution RDNS) authorization-realm-name local 

• Identity to be determined by a header in the request, using LDAP authorization. 

SGOS# (config) security policy- substitution create-realm header 
SGOS# (conf ig) security policy- substitution edit-realm header 

SGOS# (config policy-substitution header) username \ 

$ (request . x_header . username) 

SGOS# (config policy-substitution header) full-username \ 
cn=$ (request . x_header . username) , cn=users , dc=company , dc=com 
SGOS# (config policy-substitution header) username \ 
authorization-realm-name ldap 



• Identity to be determined by sending an Ident query to the client computer 

SGOS# (config) security policy- substitution create-realm ident 
SGOS# (conf ig) security policy- substitution edit-realm ident 
SGOS# (config policy-substitution ident) username $ (ident .username) 

SGOS# (config policy-substitution ident) full -username 
"cn=$ ( ident . username) , cn=Users , dc= company , dc=com" 

□ If you need to change the NetBIOS defaults of 5 seconds and 3 retries, you can use the nbstat 
requester option from the netbios command submode. (For more information on using the 
NetBIOS commands, refer to the Blue Coat ProxySG Command Line Reference.) 

□ If you need to change the Ident defaults of 30 second timeout, treating username whitespace as 
significant and querying Ident port 113, you can use the client commands in the identd 
command submode. (For more information on using the Ident commands, refer to the Blue Coat 
ProxySG Command Line Reference.) 



465 



Blue Coat ProxySG Configuration and Management Guide 



Section K: Policy Substitution Realm 

Creating the Policy Substitution Policy 

When you complete Policy Substitution realm configuration, you must create CPL policies for the 
policy-substitution realm to be used. Be aware that the example below is just part of a comprehensive 
authentication policy By themselves, they are not adequate. 

Note that, for policy substitution realms, the username and group values are case-sensitive. 



Note: Refer to the Blue Coat ProxySG Content Policy Language Guide for details about CPL and 

how transactions trigger the evaluation of policy file < Proxy > and other layers. 



Be aware that the default policy condition for this example is allow. On new SGOS 4.x systems, the 
default policy condition is deny. 

□ Every Policy Substitution realm authenticated user is allowed to access the ProxySG. 

< Proxy > 

authenticate ( PolicySubstitutionRealm) 
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Section L: Sequence Realm Authentication 

Once a realm is configured, you can associate it with other realms to allow Blue Coat to search for the 
proper authentication credentials for a specific user. That is, if the credentials are not acceptable to the 
first realm, they are sent to the second, and so on until a match is found or all the realms are 
exhausted. This is called sequencing. 

This section discusses the following topics: 

□ "Adding Realms to a Sequence Realm" 

□ "Creating a Sequence Realm" 

Adding Realms to a Sequence Realm 

Keep in mind the following rules for using realm sequences: 

□ Ensure the realms to be added to the sequence are customized to your needs. Check each realm to 
be sure that the current values are correct. For IWA, verify that the Allow Basic Credentials checkbox 
is set correctly. 

□ All realms in the realm sequence must exist and cannot be deleted or renamed while the realm 
sequence references them. 

□ Only one IWA realm is allowed in a realm sequence. 

□ If an IWA realm is in a realm sequence, it must be either the first or last realm in the list. 

□ If an IWA realm is in a realm sequence and the IWA realm does not support Basic credentials, the 
realm must be the first realm in the sequence and try IWA authentication once must be enabled. 

□ Multiple Basic realms are allowed. 

□ Connection-based realms, such as Certificate, are not allowed in the realm sequence. 

□ A realm can only exist once in a particular realm sequence. 

□ A realm sequence cannot have another realm sequence as a member. 

□ If a realm is down, an exception page is returned. Authentication is not tried against the other 
later realms in the sequence. 



467 



Blue Coat ProxySG Configuration and Management Guide 



Section L: Sequence Realm Authentication 

Creating a Sequence Realm 

To Create a Sequence Realm through the Management Console 
1. Select Configuration>Authentication>Sequences>Sequence Realms. 



Sequence Realms j Sequence Main J Sequence General 




2. Click New; the Add Sequence Realm dialog displays. 



Add Sequence Realm 



Realm name: | 

Other realm configuration parameters have been set to default values. 

( OK ] [ Cancel ] 

Figure 9-61: Add Sequence Realm 

3. In the Realm name, enter a realm name. The name can be 32 characters long and composed of 
alphanumeric characters and underscores. The name must start with a letter. 

4. Click OK. 

5. Click Apply. 

To Create a Sequence Realm through the CLI 

Up to 40 Sequence realms can be configured per ProxySG. 

At the (conf ig) command prompt, enter the following command to create a Sequence realm: 
SGOS# (config) security sequence create -realm realm_name 

where realm_name is the name of the new Sequence realm. 
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Adding Realms to a Sequence Realm 

To Add Realms to a Sequence Realm through the Management Console 

1. Select Configuration>Authentication>Sequences>Sequence Main. 

The Sequences tab displays with the Sequence realm that you want to add realms to. 



Note: You must have defined at least one sequence realm (using the Sequence Realms tab) 

before attempting to set Sequence general properties. If the message Realms must be 
added in the Sequence Realms tab before editing this tab is displayed in red at 
the bottom of this page, you do not currently have any Sequence realms defined. 



Sequence Realms Sequence Main Sequence General 



Realm name: 

Member Realms 




New 



Delete 



List order indicates preference 



Promote entry 
Demote entry 



Q Try IWA authentication only once 

Figure 9-62: Sequence Main Tab 

2. Click New to add an existing realm to the realm sequence from the drop-down list. Remember that 
each realm can be used only once in a realm sequence. 




Figure 9-63: Add Member Realm 

3. From the drop-down list, select the Sequence realm you wanted added to the realm sequence. 

4. Click OK. 

You are returned to the main Sequences menu. 
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5. Click Apply. 

6. Repeat from step 2 until you have added all necessary realms. 

7. To change the order that the realms are checked, use the promote/demote buttons. When you add 
an IWA realm, it is placed first in the list and you can allow the realm sequence to try IWA 
authentication only once. If you demote the IWA entry, it becomes last in the sequence and the 
default of checking IWA multiple times is enabled. 

8. Click Apply. 

To Add Authentication Realms to a Sequence Realm through the CLI 

1. From the (config) prompt, add existing realms to the new specified sequence realm name: 

SGOS# (config) security sequence edit-realm realm_sequence_name 
SGOS# (config sequence realm_sequence_name ) realm add realm_name 

2. Repeat the realm add realm_name command until all necessary realms have been added. 

3. (Optional) Give the new sequence realm a display name. The default value for the display name is 
the realm name. The display name cannot be longer than 128 characters and it cannot be null. 
SGOS# (config sequence realm_sequence_name ) display-name display_name 

Defining Sequence Realm General Properties 

The Sequence General tab allows you to specify the display name and a virtual URL. 

1. Select Configuration>Authentication>Sequences>Sequence General. 

Sequence Realms | Sequence Main Sequence General 



|Sequence_1 



Display name: Sequ enc eJ 

r Virtual URL 

URL: [ | 

Figure 9-64: Sequence General Tab 

2. From the Realm name drop-down list, select the Sequence realm for which you want to change 
properties. 



Note: You must have defined at least one sequence realm (using the Sequence Realms tab) 

before attempting to set Sequence general properties. If the message Realms must be 
added in the Sequence Realms tab before editing this tab is displayed in red at 
the bottom of this page, you do not currently have any Sequence realms defined. 



3. If needed, change the Sequence realm display name. The default value for the display name is the 
realm name. The display name cannot be longer than 128 characters and it cannot be null. 
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4. You can specify a virtual URL based on the individual realm sequence. For more information on 
the virtual URL, see "Understanding Origin-Style Redirection" on page 326. 

5. Click Apply. 



To Manage Authentication Realms in a Sequence Realm through the CLI 

1. When you add an IWA realm it is placed first in the list, and you have the option of allowing the 
realm sequence to try IWA authentication only once. If you demote the IWA entry, it becomes last in 
the sequence and the default of checking IWA multiple times is enabled. 

SGOS# (config sequence realm_sequence_name ) IWA-only-once-enable 

% An IWA realm must be the first member of the realm sequence before specifying 
to try IWA authentication only once 

SGOS# (config sequence realm_sequence_name ) realm promote IWA1 
SGOS# (config sequence realm_sequence_name ) IWA-only-once-enable 

2. (Optional) You can specify a virtual URL based on the individual realm sequence. For information 
on the virtual URL, see "Understanding Origin-Style Redirection" on page 326. 

SGOS# (config sequence realm_sequence_name ) virtual-url 10.25.36.4 7 
ok 



3. View the configuration. 

a. To view the configuration of the current realm sequence, remain in the submode and 
enter: 



b. 



SGOS# (config sequence realm_sequence_name ) 
Realm name : seql 

Display name : seql 

Virtual URL: 10.25.36.47 

Try IWA only once: yes 

Member realms : IWA1 



radiusl 

test 

ldapl 



view 



To view the configurations of all realm-sequence-names, exit the edit -realm submode, 
and enter: 



SGOS# (config sequence realm_sequence_name ) 
SGOS# (config) security sequence view 



Realm name : 

Display name : seql 
Virtual URL: 

Try IWA only once : 
Member realms : 



seql 

10.25.36.47 

yes 



IWA1 

radiusl 

test 

ldapl 

Realm name : seq2 

Virtual URL: 

Try IWA only once : no 

Member realms : ldapl 

ldap2 



exit 
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Tips 

□ Explicit Proxy involving a sequence realm configured with an NTLM/IWA realm and a 
substitution realm. 

Internet Explorer (IE) automatically sends Windows credentials in the Proxy- Authorization: 
header when the ProxySG issues a challenge for NTLM/IWA. The prompt for 
username/password appears only if NTLM authentication fails. However, in the case of a 
sequence realm configured with an NTLM/IWA realm and a substitution realm, the client is 
authenticated as a guest in the policy substitution realm, and the prompt allowing the user to 
correct the NTLM credentials never appears. 

□ Transparent Proxy setup involving a sequence realm configured with an NTLM /IWA realm and a 
substitution realm. 

The only way the ProxySG can differentiate between a domain and non-domain user is though 
the NTLM/IWA credentials provided during the authentication challenge. 

IE does not offer Windows credentials in the Proxy- Authorization: header when the Proxy issues 
a challenge for NTLM/IWA unless the browser is configured to do so. In this case, the behavior is 
the same as for explicit proxy. 

If IE is not configured to offer Windows credentials, the browser issues a prompt for 
username/password, allowing non-domain users to be authenticated as guests in the policy 
substitution realm by entering worthless credentials. 
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Section M: Forms-Based Authentication 

You can use forms-based authentication exceptions to control what your users see during 
authentication. You can: 

□ Specify the realm the user is to authenticate against. 

□ Specify that the credentials requested are for the SG appliance. This avoids confusion with other 
authentication challenges. 

□ Make the form comply with company standards and provide other information, such as a help 
link. 

The authentication form (an HTML document) is served when the user makes a request and requires 
forms-based authentication. If the user successfully authenticates to the SG appliance, the appliance 
redirects the user back to the original request. 

If the user does not successfully authenticate against the SG appliance and the error is 
user-correctable, the user is presented with the authentication form again. 



Note: You can configure and install an authentication form and several properties through the 

Management Console and the CLI, but you must use policy to dictate the authentication 
form's use. 



With forms-based authenticating, you can set limits on the maximum request size to store and define 

the request object expiry time. You can also specify whether to verify the client's IP address against the 

original request and whether to allow redirects to the original request. 

To create and put into use forms-based authentication, you must complete the following steps: 

□ Create a new form or edit one of the existing authentication form exceptions 

□ Set storage options 

□ Set policies 

Understanding Authentication Forms 

Three authentication forms are created initially: 

□ authentication_form: Enter Proxy Credentials for Realm $(cs-realm). This is the standard 
authentication form that is used for authentication with the ProxySG. 

□ new_pin_form: Create New PIN for Realm $(cs-realm). This form is used if you created a RADIUS 
realm using RSA SecurlD tokens. This form prompts the user to enter a new PIN. The user must 
enter the PIN twice in order to verify that it was entered correctly. 

□ query_form: Query for Realm $(cs-realm). This form is used if you created a RADIUS realm using 
RSA SecurlD tokens. The form is used to display the series of yes /no questions asked by the 
SecurlD new PIN process. 
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You can customize any of the three initial authentication form exceptions or you can create other 
authentication forms. (You can create as many authentication form exceptions as needed. The form 
must be a valid HTML document that contains valid form syntax.) 

Each authentication form can contain the following: 

□ Title and sentence instructing the user to enter ProxySG credentials for the appropriate realm. 

□ Domain: Text input with maximum length of 64 characters The name of the input must be 
proxy_sg_domain / and you can specify a default value of $ (x-cs-auth-domain) so that the 
user's domain is prepopulated on subsequent attempts (after a failure). 

The input field is optional, used only if the authentication realm is an IWA realm. If it is used, the 
value is prepended to the username value with a backslash. 

□ Username: Text input with maximum length of 64 characters. The name of the input must be 
proxy_sg_username, and you can specify a default value of $ (cs-username) so the 
username is prepopulated on subsequent attempts (after a failure). 

□ Password: The password should be of type password with a maximum length of 64 
characters. The name of the input must be proxy_sg_password. 

□ Request ID: If the request contains a body, then the request is stored on the ProxySG until the user 
is successfully authenticated. 

The request ID should be of type hidden. The input name must be proxy_sg_request_id, 
and the value must be $ (x-cs-auth-request-id) . The information to identify the stored 
request is saved in the request id variable. 

□ Challenge State: The challenge state should be of type hidden. If a RADIUS realm is using 
a response/ challenge, this field is used to cache identification information needed to correctly 
respond to the challenge. 

The input name must be proxy_sg_private_challenge_state, and the value must be 
$ (x-auth-private-challenge-state) . 

□ Submit button. The submit button is required to submit the form to the ProxySG. 

□ Clear form button. The clear button is optional and resets all form values to their original values. 

□ Form action URI: The value is the authentication virtual URL plus the query string containing the 
base64 encoded original URL $ (x-cs-auth-form-action-url) . 

□ Form METHOD of POST. The form method must be POST. The ProxySG does not process forms 
submitted with GET. 

The ProxySG only parses the following input fields during form submission: 

□ proxy_sg_username (required) 

□ proxy_sg_p as sword (required) 

□ proxy_sg_request_id (required) 

□ proxy_sg_private_challenge_state (required) 
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□ PROXY_SG_DOMAlN (optional) If specified, its value is prepended to the username and separated 
with a backslash. 

Authentication_form 

The initial form, authentication_form, looks similar to the following: 

<HTML> 

<HEAD> 

<TITLE>Enter Proxy Credentials for Realm $ (cs-realm) </TITLE> 

< / HEAD > 

<BODY> 

<Hl>Enter Proxy Credentials for Realm $ (cs-realm) </Hl> 

<P>Reason for challenge: $ (exception. last_error) 

<P>$ (x-auth-challenge-string) 

<FORM METHOD= " POST" ACTION=$ (x- cs -auth- form-act ion-url ) > 

$ (x-cs-auth-form-domain-f ield) 

<P>Username: <INPUT NAME= " PROXY_SG_USERNAME " MAXLENGTH= " 64 " 

VALUE=$ (cs-username) ></P> 

<P>Password: <INPUT TYPE=PASSWORD NAME="PROXY_SG_PASSWORD" MAXLENGTH= " 64 " ></P> 
< INPUT TYPE=HIDDEN NAME= " PROXY_SG_REQUEST_ID " VALUE=$ (x-cs -auth- request - id) > 

< INPUT TYPE=HIDDEN NAME= " PROXY_SG_PRIVATE_CHALLENGE_STATE " 

VALUE=$ (x-auth-private-challenge-state) > 

<P>< INPUT TYPE=SUBMIT VALUE =" Submit " > <INPUT TYPE=RESETx/P> 

</FORM> 

<P>$ (exception . contact) 

</BODY> 

</HTML> 

If the realm is an IWA realm, the $ (x-cs-auth-form-domain-f ield) substitution expands to: 

<P>Domain: <INPUT NAME=PROXY_SG_DOMAIN MAXLENGTH= 6 4 VALUE=$ (x-cs-auth-domain) > 

If you specify $ (x-cs-auth-form-domain-f ield) , you do not need to explicitly add the domain 
input field. 

For comparison, the new_pin_form and query_form look similar to the following: 

New_pin_form 

<HTML> 

<HEAD> 

<TITLE>Create New PIN for Realm $ (cs-realm) </TITLE> 

<SCRIPT LANGUAGE= "JavaScript ">< ! -- 
function validatePin ( ) { 

var info; 

var pin = document . pin_form . PROXY_SG_PAS SWORD ; 

if (pin. value != document .pin_form. PROXY_SG_RETYPE_PIN. value) { 
info = "The PINs did not match. Please enter them again."; 

} else { 

// Edit this regular expression to match local PIN definition 
var re=/^ [A-Za- zO - 9] {4 , 16 } $/ 
var match=re . exec (pin. value) ; 
if (match == null) { 

info = "The PIN must be 4 to 16 alphanumeric characters"; 
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} else { 

return true; 

} 

} 

alert (info) ; 
pin . select ( ) ; 
pin . focus ( ) ; 
return false; 

}// --> 

</ script> 

< / HEAD > 

<BODY> 

<Hl>Create New PIN for Realm $ (cs-realm) </Hl> 

<P>$ (x-auth-challenge-string) 

<FORM NAME= "pinf orm" METHOD= " POST" 

ACTION=$ (x-cs-auth-form-action-url) ONSUBMIT= " return validatePin ( ) " > 

$ (x-cs-auth-form-domain-f ield) 

<P> Enter New Pin: <INPUT TYPE=PASSWORD NAME= " PROXY_SG_PASSWORD " 

MAXLENGTH = "64"></P> 

<P>Retype New Pin: <INPUT TYPE=PASSWORD NAME= " PROXY_SG_RETYPE_PIN" 

MAXLENGTH= " 6 4 " > < / P > 

< INPUT TYPE=HIDDEN NAME= " PROXY_SG_USERNAME " VALUE=$ ( cs -username ) > 

< INPUT TYPE=HIDDEN NAME= " PROXY_SG_REQUEST_ID " VALUE=$ (x-cs -auth- request - id) > 
< INPUT TYPE=HIDDEN NAME= " PROXY_SG_PRIVATE_CHALLENGE_STATE " 

VALUE=$ (x-auth-private-challenge-state) > 

<P>< INPUT TYPE=SUBMIT VALUE= " Submit ">< /P> 

</FORM> 

<P>$ (exception . contact) 

</BODY> 

</HTML> 

Query_form 

<HTML> 

<HEAD> 

<TITLE>Query for Realm $ (cs-realm) </TITLE> 

< / HEAD > 

<BODY> 

<Hl>Query for Realm $ (cs-realm) </Hl> 

<P>$ (x-auth-challenge-string) 

<FORM METHOD= " POST " ACTION=$ (x- cs -auth- form-act ion-url ) > 

$ (x-cs-auth-form-domain-f ield) 

< INPUT TYPE=HIDDEN NAME= " PROXY_SG_USERNAME " VALUE=$ ( cs -username ) > 

< INPUT TYPE=HIDDEN NAME= " PROXY_SG_REQUEST_ID " VALUE=$ (x-cs -auth- request - id) > 
< INPUT TYPE=HIDDEN NAME= " PROXY_SG_PRIVATE_CHALLENGE_STATE " 

VALUE=$ (x-auth-private-challenge-state) > 

< INPUT TYPE=HIDDEN NAME= " PROXY_SG_PASSWORD " " > 

<P>< INPUT TYPE= SUBMIT VALUE="Yes" ONCLICK= " PROXY_SG_PAS SWORD . value= 1 Y ' " > 

< INPUT TYPE=SUBMIT VALUE="No" ONCLICK= " PROXY_SG_PAS SWORD . value= ' N ' " ></P> 
</FORM> 

<P>$ (exception . contact) 
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</BODY> 

</HTML> 

User/Realm CPL Substitutions for Authentication Forms 



CPL user /realm substitutions that are common in authentication form exceptions are listed below. 
The syntax for a CPL substitution is: 



$(CPL_substitution) 

group 

groups 

realm 

user 

cs-realm 



user-name 

user .x509 . issuer 

user .x509 . serialNumber 

user . x5 0 9 . sub j ect 

x-cs-auth- request -id 

x-auth -private- challenge- state 



x-cs-auth- request -id 
x-cs -auth- domain 
x-cs -auth- form- domain- field 
x-cs -auth- form- act ion-url 
x-auth- challenge- string 



Note: Any substitutions that are valid in CPL and in other exceptions are valid in authentication 

form exceptions. 



For a discussion of using CPL and a complete list of CPL substitutions, as well as a description of each 
substitution, refer to the Blue Coat ProxySG Content Policy Language Guide. 



There is no realm restriction on the number of authentication form exceptions you can create. You can 
have an unlimited number of forms, although you might want to make them as generic as possible to 
cut down on maintenance. 

Creating and Editing a Form 

You can create a new form or you can edit one of the existing ones. If you create a new form, you need 
to define its type (authentication_form, new_pin_form, or query_form). The form is created from the 
default definition for that type. Editing the initial forms does not affect how future forms are created. 

To Create or Edit an Authentication Form through the Management Console 
1. Select Configuration>Authentication>Forms. 

The Authentication Forms tab displays. 
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Authentication Forms 

■ Authentication Forms — 



Name 


Type 


authentication_form 


authentication_form 


new_pin_form 


new_pin_form 


queryjorm 


queryjorm 





New 



Edit 



Delete 



View 




Figure 9-65: Authentication Forms 
2. Select one of the buttons below the authentication forms: 
• Highlight the form you want to edit, delete, or view. 



Note: View in the Authentication Forms panel and View in the Default Definitions panel 

have different functions. View in the Authentication Forms panel allows you to view 
the form you highlighted; View in the Default Definitions panel allows you view the 
original, default settings for each form. This is important in an upgrade scenario; any 
forms already installed will not be changed. You can compare existing forms to the 
default version and decide if your forms need to be modified. 



3. 



• Click New to create a new form. 

Creating a New Form 

• The New button works independently of the highlighted form. The template used for the new 
form is chosen from the Add Authentication Form dialog. 



Add list item 



r Add Authentication Form 
Name: | 

Type: Authentication Form 



| OK | | Cancel | 

Figure 9-66: Authentication Form Dialog 

• Enter the form name and select the authentication type from the dropdown menu. 
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• Click OK. 

4. Editing a Form 

• If you highlight the form you want to edit and click Edit, the Edit Authentication dialog displays. 



Edit Authentication Form new_pin_form 



Edit Authentication Form new_pin_form 

Install Authentication Form from: Remote URL v 



Install 



OK 



[ Cancel ] 



Figure 9-67: Edit Authentication Form Dialog 

• From the drop-down list, select the method to use to install the authentication form; click 
Install. 



• Remote URL: 



Enter the fully-qualified URL, including the filename, where the authentication form 
is located. To view the file before installing it, click View. Click Install. To view the 
results, click Results; to close the dialog when through, click OK. 



Install Authentication Form 



Install Authentication Form 

Installation URL: 




OK ~| | Cancel ] Results 

Figure 9-68: Specifying the Remote Location of an Authentication Form 
• Local File: 

Click Browse to bring up the Local File Browse window. Browse for the file on the local 
system. Open it and click Install. When the installation is complete, a results window 
opens. View the results; to close the window, click Close. 
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Figure 9-69: Specifying the Local Location of an Authentication Form 
• Text Editor: 

The current authentication form is displayed in the text editor. You can edit the form 
in place. Click Install to install the form. When the installation is complete, a results 
window opens. View the results; to close the window, click Close. 
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BlueQCoat 



Edit and Install the exception queryfonn 

1 . Edit the contents of the currently installed file in the box below. 

2. Click Install to upload and install the new contents. It can take some time for the upload to complete. 

Your browser may be unresponsive during the upload. 

3. Once the installation is completed the results will be displayed in a new page. Close the results page 
once you have finished viewing the results. 

<HTML> 

<HEAD> 

<TITLE>Query for Realm § (cs-realm) </TITLE> 

</HEAD> 

<BODY> 

<Hl>Query for Realm $ (cs-realm) </Hl> 

<P>$ (x-auth-challenge-str ing) 

<FORM HE THOD = " P OS T " ACTION=$ (x-cs-auth-f orm-act ion-ur 1) > 

$ (x-cs-auth-f orm-domain-f ield) 

< INPUT TYPE=HIDDEN NAHE= ,r PROXY_SG_USERNAHE " VALUE=$ (cs-username) > 

< INPUT TYPE=HIDDEN NAME="PROXY_SG_REQUEST_ID" VALUE=$ (x-cs-auth-request-id) > 
< INPUT TYPE=HIDDEN NAME="PROXY_SG_PRIVATE_CHALLENGE_STATE" 

VALUE=$ (x-auth-private-challenge-state) > 

< INPUT TYPE=HIDDEN NAME="PROXY_SG_P ASS WORD ""> 

<P>< INPUT TYPE=SUBHIT VALUE="Yes" ONCLICK =,, PROXY_SG_PASSWORD . value= 1 Y' "> 

< INPUT TYPE=SUBHIT VALUE="No" ONCLICK="PROXY_SG_P AS SWORD . value= ' N' "></P> 
</FORH> 

<P>$ (exception. contact) 

</BODY> 

</HTHL> 



1 Install 1 | Close | 

Figure 9-70: Using the ProxySG Text Editor 
To Create a Form through the CLI 

Remember that if you create a new form, the new form uses the authentication form you choose as a 
template. You can revert a form to its original state using the authentication-forms revert 
command. 

To create a new form, enter the following command from the (config) prompt 

SGOS# (config) security authentication- forms 

The prompt changes to 

SGOS# (config authentication-forms) 

SGOS# (config authentication-forms) create form_type form_name 
ok 

where form_type indicates the default authentication- form, new-pin- form, or 
query- form and form_name is the name you give the form . 

To view all the authentication forms on the system, enter the following command: 
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SGOS# (config authentication-forms) view 

Authentication forms: 

auth_testl 

authentication_form 

ne w_p i n_f o rra 

npf_testll 

query_form 

query_testl 

To Edit a Form through the CLI 

You cannot edit a form in place through the CLI. You can replace a form though using either remote 
download or through the ProxySG Appliance's inline commands. 

To Revert a Form to the Default Settings 

If you created a custom form and later decide that the form should have the default settings of the 
template, you can revert the form by entering the command: 

SGOS# (config) security authentication- forms 

SGOS# (config authentication-forms) revert form_name 
ok 

To Edit a Form using Inline Commands: 

SGOS# (config authentication-forms) inline form_name end-of-file_marker 
-or- 

SGOS# inline authentication- form form_name end-of-file_marker 
-or- 

SGOS# inline authentication- forms end-of-file_marker 

Remember that any form you modify must contain the username, password, request ID, and 
challenge state. 

A form that is missing these values results in the user receiving an error page when the form is 
submitted. For more information on required fields in a new authentication form, see "Understanding 
Authentication Forms" on page 473. 



Note: You can also import the entire set of forms through the inline authentication-forms 

command. 



Notes on using inline commands: 

□ If you make a mistake on the current line of the script you are typing, you can backspace to correct 
the problem. 

□ If you notice a mistake on a previous line, you must quit the script (by using <Ctrl-c>) and start 
over. 

□ The inline script overwrites the existing template. 

To Create and Download a Form using a Text Editor: 

1. Create the authentication form as a text file. 
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2. Place the form on a server that is accessible to the ProxySG. 



Note: You cannot download a form until it is created. 



3. Enter the following commands to give the ProxySG the file's location and to download the file: 

SGOS# (config) security authentication- forms 

SGOS# (config authentication-forms) path form_name 
SGOS# (config authentication-forms) load form_name 
-or- 

SGOS#load authentication- forms form name 



Note: You can download one or all forms using the above commands. 



To Delete an Authentication Form 

From the (config) prompt, enter the following commands: 

SGOS# (config) security authentication- forms 

SGOS# (config authentication-forms) delete form_name 

where form_name is the name of the form you want to delete. 

Setting Storage Options 

When a request requiring the user to be challenged with a form contains a body, the request is stored 
on the SG appliance while the user is being authenticated. Storage options include: 

□ the maximum request size. 

□ the expiration of the request. 

□ whether to verify the IP address of the client requesting against the original request. 

□ whether to allow redirects from the origin server 

The storage options are global, applying to all form exceptions you use. 

The global allow redirects configuration option can be overridden on a finer granularity in policy 
using the authenticate . redirect_stored_requests (yes | no) action. 
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To Set Storage Options through the Management Console 
1. Select Configuration>Authentication>Request Storage. 

Request Storage 




Figure 9-71 : Request Storage Tab 

2. In the Maximum request size to store (Megabytes) field, enter the maximum POST request size 
allowed during authentication. The default is 50 megabytes. 

3. In the Request object expiry time (seconds) field, enter the amount of time before the stored request 
expires. The default is 300 seconds (five minutes). The expiry time should be long enough for the 
user to fill out and submit the authentication form. 

4. If you do not want the ProxySG to Verify the IP address against the original request, deselect that 
option. The default is to verify the IP address. 

5. To Allow redirects from the origin servers, select the checkbox. The default is to not allow redirects 
from origin servers. 



Note: During authentication, the user's POST is redirected to a GET request. The client therefore 

automatically follows redirects from the origin server. Because the ProxySG is converting 
the GET to a POST and adding the post data to the request before contacting the origin 
server, the administrator must explicitly specify that redirects to these POSTs requests can 
be automatically followed. 



6. Click Apply. 



To Set Storage Options through the CLI 



From the (config) prompt, enter the following commands to select storage options: 



SGOS# (config) 
SGOS# (config) 
SGOS# (config) 
SGOS# (config) 



security- 

security 

security 

security 



request-storage 

request-storage 

request-storage 

request-storage 



max- size megabytes 
expiry- time seconds 
verify-ip enable | disable 
allow-redirects enable | disable 



where 



max-size 


megabytes 


Sets the maximum POST request size during 






authentication. The default is 5 0 megabytes. 
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expiry-time 


seconds 


Sets the amount of time before the stored request 
expires. The default is 3 0 0 seconds (five minutes). 


verify- ip 


enable | disable 


Enables or disables the verify-ip option. The 
default is to enable the ProxySG to verify the IP 
address against the original request. 


allow- redirects 


enable | disable 


Specifies whether to allow redirects. The default is 
disable. 



Using CPL with Forms-Based Authentication 

To use forms-based authentication, you must create policies that enable it and also control which form 
is used in which situations. A form must exist before it can be referenced in policy. 

□ Which form to use during authentication is specified in policy using one of the CPL conditions 
authenticate . form ( form_name ) , authenticate . new_pin_form ( form_name) , or 
authenticate . query_form (form_name) . 



These conditions override the use of the initial forms for the cases where a new pin form needs to 
be displayed or a query form needs to be displayed. All three of the conditions verify that the 
form name has the correct type. 



Note: Each of these conditions can be used with the form authentication modes only. If no form 

is specified, the form defaults to the CPL condition for that form. That is, in no name is 
specified for authenticate . form ( f orm_name), the default is authentication_f orra; if 
no name is specified for authenticate . new_pin_f orm ( f orm_name) , the default is 
authenticate . new_pin_f orm, and if no name is specified for 

authenticate . query_form ( f orm_name) , the default is authenticate . query_f orm. 



□ Using the authentication. mode ( ) property selects a combination of challenge type and 

surrogate credentials. The authentication . mode ( ) property offers several options specifically 
for forms-based authentication: 

• Form- IP — The user's IP address is used as a surrogate credential. The form is presented 
whenever the user's credential cache entry expires. 

• Form-Cookie — Cookies are used as surrogate credentials. The cookies are set on the OCS 
domain only, and the user is presented with the form for each new domain. This mode is most 
useful in reverse proxy scenarios where there are a limited number of domains. 

• Form-Cookie-Redirect — The user is redirected to the authentication virtual URL before the form 
is presented. The authentication cookie is set on both the virtual URL and the OCS domain. 
The user is only challenged when the credential cache entry expires. 

• Form-1 P-redirect — This is similar to Form-1 P except that the user is redirected to the 
authentication virtual URL before the form is presented. 
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□ If you authenticate users who have third-party cookies explicitly disabled, you can use the 
authenticate . use_url_cookie ( ) property 

□ Since the authentication . mode ( ) property is defined as a form mode (above) in policy, you do 
not need to adjust the default authenticate mode through the CLI. 

□ Using the authenticate . redirect_stored_requests (yes | no) action allows granularity in 
policy over the global allow redirect config option. 

For information on using these CPL conditions and properties, refer to the Blue Coat ProxySG Content 

Policy Language Guide. 

Tips and Boundary Conditions 

□ If the user is supposed to be challenged with a form on a request for an image or video, the 
ProxySG returns a 403 error page instead of the form. If the reason for the challenge is that the 
user's credentials have expired and the object is from the same domain as the container page, then 
reloading the container page results in the user receiving the authentication form and being able 
to authenticate. However, if the client browser loads the container page using an existing 
authenticated connection, the user might still not receive the authentication form. 

Closing and reopening the browser should fix the issue. Requesting a different site might also 
cause the browser to open a new connection and the user is returned the authentication form. 

If the container page and embedded objects have a different domain though and the 
authentication mode is form-cookie, reloading or closing and reopening the browser might not fix 
the issue, as the user is never returned a cookie for the domain the object belongs to. In these 
scenarios. Blue Coat recommends that policy be written to either bypass authentication for that 
domain or to use a different authentication mode such as form-cookie-redirect for that domain. 

□ Forms-based authentication works with HTTP browsers only. 

□ Because forms only support Basic authentication, authentication-form exceptions cannot be used 
with a Certificate realm. If a form is in use and the authentication realm is or a Certificate realm, 
you receive a configuration error. 

□ User credentials are sent in plain text. However, they can be sent securely using SSL if the virtual 
URL is HTTPS. 

□ Because not all user requests support forms (such as WebDAV and streaming), create policy to 
bypass authentication or use a different authentication mode with the same realm for those 
requests. 
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Section N: Managing the Credential Cache 

When you have configured all your realms, you can view your realms and manage the credentials 
cache for a specific realm. 

To Manage the Credential Cache through the Management Console 
1. Select to Configuration>Authentication>Realms. 

The Realms page displays, with all realms that you have created. 

Realms 

r Realms 



Realm name Protocol 


local 1 


Local 


Idapl 


LDAP 


certificate 1 


Certificate 


Sequence_l 


Sequence 


SMI 


SiteMinder 


COREidl 


COREid 


PS1 


Policy Substitution 



Realms can be created, modified and deleted within individual protocols. 



- Credentials cache 

pi Flush when policy file changes [ Flush | entire cache now 

I Flush realm [ Flush realm: | oca n v now 

Figure 9-72: Viewing All Realms on the ProxySG 

2. To manage the credential cache: 

• To purge the credentials cache when you make policy changes, select Flush When Policy File 
Changes (this option is selected by default). 

• To flush the entire credentials cache immediately, click Flush and confirm. 

• To flush only the entries for a particular realm in the credentials cache, select the realm from 
the drop-down list, click Flush Realm confirm. 

All of these actions force users to be re-authenticated. 

3. Click Apply. 

To Manage the Credential Cache through the CLI 

From the (config) command prompt, enter the following command: 

SGOS# (config) security flush-credentials <cr> [on-policy-change {enable | 
disable} | realm realm ] 

where: 



<cr> 




Press the <Enter> key to flush the credential cache 
now. 


on-policy- change 


enable | disable 


Flush the cache only if the policy changes. 



local 1 
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realm 



realm 



Flush the credential cache for the specified realm. 



Notes 

□ For all realms except IWA, SiteMinder, and COREid, the maximum number of entries stored in the 
credential cache is 80,000. 

For IWA, SiteMinder, and COREid authentication, the maximum number of entries stored in the 
credential cache is dependent on the system. You can have at least 2500 entries but potentially 
more depending on the system resources. 

□ XFTP users are not prompted for proxy authentication if the credentials are in the cache and the 
credentials have not expired. 
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Bandwidth management (BWM) allows you to classify, control, and, if required, limit the amount of 
bandwidth used by different classes of network traffic flowing into or out of the ProxySG. Network 
resource sharing (or link sharing) is done using a bandwidth-management hierarchy where multiple 
traffic classes share available bandwidth in a controlled manner. 



Note: The ProxySG does not try to reserve any bandwidth on the network links that it is 

attached to or otherwise guarantee that the available bandwidth on the network can 
sustain any of the bandwidth limits which have been configured on it. The ProxySG can 
only shape the various traffic flows passing through it, and prioritize some flows over 
others according to its configuration. 



By managing the bandwidth of specified classes of network traffic, you can do the following: 

□ Guarantee that certain traffic classes receive a specified minimum amount of available bandwidth. 

□ Limit certain traffic classes to a specified maximum amount of bandwidth. 

O Prioritize certain traffic classes to determine which classes have priority over available bandwidth. 

Bandwidth Management Terms 

Some of the terms used in this document are described below. 

□ Bandwidth Class: A defined unit of bandwidth allocation. An administrator uses bandwidth 
classes to allocate bandwidth to a particular type of traffic flowing through the ProxySG. 

n Bandwidth Class Hierarchy: Bandwidth classes can be grouped together in a class hierarchy, 
which is a tree structure that specifies the relationship among different classes. You create a 
hierarchy by creating at least one parent class and assigning other classes to be its children. 

□ Bandwidth Policy: The set of rules that you define in the policy layer to identify and classify the 
traffic in the ProxySG, using the bandwidth classes that you create. You must use policy (through 
either VPM or CPL) in order to manage bandwidth. 

□ Child Class: The child of a parent class is dependent upon that parent class for available 
bandwidth (they share the bandwidth in proportion to their minimum / maximum bandwidth 
values and priority levels). A child class with siblings (classes with the same parent class) shares 
bandwidth with those siblings in the same manner. 

□ Inbound Traffic: Network packets flowing into the ProxySG. Inbound traffic mainly consists of the 
following: 

• Server inbound: Packets originating at the origin content server (OCS) and sent to the 
ProxySG to load a Web object. 

• Client inbound: Packets originating at the client and sent to the ProxySG for Web requests. 

D OCS: Origin content server. 
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□ Outbound Traffic: Network packets flowing out of the ProxySG. Outbound traffic mainly consists 
of the following: 

• Client outbound: Packets sent to the client in response to a Web request. 

• Server outbound: Packets sent to an OCS or upstream proxy to request a service. 

□ Parent Class: A class with at least one child. The parent class must share its bandwidth with its 
child classes in proportion to the minimum/ maximum bandwidth values or priority levels. 

□ Sibling Class: A bandwidth class with the same parent class as another class. 

□ Traffic Flow: Also referred to as flow. A set of packets belonging to the same TCP /UDP connection 
that terminate at, originate at, or flow through the ProxySG. A single request from a client 
involves two separate connections. One of them is from the client to the ProxySG, and the other is 
from the ProxySG to the OCS. Within each of these connections, traffic flows in two directions — in 
one direction, packets flow out of the ProxySG (outbound traffic), and in the other direction, 
packets flow into the ProxySG (inbound traffic). Connections can come from the client or the 
server. Thus, traffic can be classified into one of four types: 

• Server inbound 

• Server outbound 

• Client inbound 

• Client outbound 

These four traffic flows represent each of the four combinations described above. Each flow 
represents a single direction from a single connection. 

Bandwidth Management Overview 

To manage the bandwidth of different types of traffic that flow into, out of, or through the ProxySG, 
you must do the following: 

□ Determine how many bandwidth classes you need and how to configure them to accomplish your 
bandwidth management goals. This includes determining the structure of one or more bandwidth 
hierarchies if you want to use priority levels to manage bandwidth. 

□ Create and configure bandwidth classes accordingly. 

□ Create policy rules using those bandwidth classes to identify and classify the traffic in the 
ProxySG. 

□ Enable bandwidth management. 

Bandwidth management configuration consists of two areas: 

□ Bandwidth allocation 

This is the process of creating and configuring bandwidth classes and placing them into a bandwidth 
class hierarchy. This process can be done using either the Management Console or the CLI. 
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□ Flow classification 

This is the process of classifying traffic flows into bandwidth management classes using policy 
rules. Policy rules can classify flows based on any criteria testable by policy. You can create policy 
rules using either the Visual Policy Manager (VPM), which is accessible through the Management 
Console, or by composing Content Policy Language (CPL). 

Allocating Bandwidth 

The process of defining bandwidth classes and grouping them into a bandwidth class hierarchy is 
called bandwidth allocation. Bandwidth allocation is based on: 

□ the placement of classes in a hierarchy (the parent/ child relationships) 

□ the priority level of classes in the same hierarchy 

□ the minimum and / or maximum bandwidth setting of each class 

For example deployment scenarios, see "Bandwidth Allocation and VPM Examples" on page 502. 

Bandwidth Classes 

To define a bandwidth class, you create the class, giving it a name meaningful to the purpose for 
which you are creating it. You can configure the class as you create it or edit it later. The configuration 
settings available are: 

□ Parent: Used to create a bandwidth-management hierarchy. 

□ Minimum Bandwidth: Minimum amount of bandwidth guaranteed for traffic in this class. 

□ Maximum Bandwidth: Maximum amount of bandwidth allowed for traffic in this class. 

□ Priority: Relative priority level among classes in the same hierarchy. 

Parent Class 

A parent class is a class that has children. When you create or configure a bandwidth class, you can 
specify another class to be its parent (the parent class must already exist). Both classes are now part of 
the same bandwidth-class hierarchy, and so are subject to the hierarchy rules (see "Class Hierarchy 
Rules and Restrictions" on page 492). 

Minimum Bandwidth 

Setting a minimum for a bandwidth class guarantees that class receives at least that amount of 
bandwidth, if the bandwidth is available. If multiple hierarchies are competing for the same available 
bandwidth, or if the available bandwidth is not enough to cover the minimum, bandwidth 
management is not be able to guarantee the minimums defined for each class. 



Note: The ProxySG does not try to reserve any bandwidth on the network links that it is 

attached to or otherwise guarantee that the available bandwidth on the network can be 
used to satisfy bandwidth class minimums. The ProxySG can only shape the various 
traffic flows passing through it, and prioritize some flows over others according to its 
configuration. 



491 



Blue Coat Proxy SG Configuration and Management Guide 



Maximum Bandwidth 

Setting a maximum for a bandwidth class puts a limit on how much bandwidth is available to that 
class. It does not matter how much bandwidth is available; a class can never receive more bandwidth 
than its maximum. 

To keep a bandwidth class from using more than its maximum, the ProxySG inserts delays before 
sending packets associated with that class until the bandwidth used is no more than the specified 
maximum. This results in queues of packets (one per class) waiting to be sent. These queues allow the 
ProxySG to use priority settings to determine which packet gets sent next. If no maximum bandwidth 
is set, every packet is sent as soon as it arrives, so no queue is built and nothing can be prioritized. 

Unlike minimums and priority levels, the maximum-bandwidth setting can slow down traffic on 
purpose. Unused bandwidth can go to waste with the maximum-bandwidth setting, while the 
minimum-bandwidth settings and priority levels always distributes any unused bandwidth as long as 
classes request it. However, priority levels are not meaningful without a maximum somewhere in the 
hierarchy. If a hierarchy has no maximums, any class in the hierarchy can request and receive any 
amount of bandwidth regardless of its priority level. 

Priority 

When sharing excess bandwidth with classes in the same hierarchy, the class with the highest priority 
gets the first opportunity to use excess bandwidth. When the high-priority class uses all the 
bandwidth it needs or is allowed, the next class gets to use the bandwidth, if any remains. If two 
classes in the same hierarchy have the same priority, then excess bandwidth is shared in proportion to 
their maximum bandwidth setting. 

Class Hierarchies 

Bandwidth classes can be grouped together to form a class hierarchy. Creating a bandwidth class 
allows you to allocate a certain portion of the available bandwidth to a particular type of traffic. 
Putting that class into a bandwidth-class hierarchy with other bandwidth classes allows you to specify 
the relationship among various bandwidth classes for sharing available (unused) bandwidth. 

The way bandwidth classes are grouped into the bandwidth hierarchy determines how they share 
available bandwidth among themselves. You create a hierarchy so that a set of traffic classes can share 
unused bandwidth. The hierarchy starts with a bandwidth class you create to be the top-level parent. 
Then you can create other bandwidth classes to be the children of the parent class, and those children 
can have children of their own. 

In order to manage the bandwidth for any of these classes, some parent in the hierarchy must have a 
maximum bandwidth setting. The classes below that parent can then be configured with minimums 
and priority levels to determine how unused bandwidth is shared among them. If none of the higher 
level classes have a maximum bandwidth value set, then bandwidth flows from the parent to the child 
classes without limit. In that case, minimums and priority levels are meaningless, because all classes 
get all the bandwidth they need at all times. The bandwidth, in other words, is not being managed. 

Class Hierarchy Rules and Restrictions 

Certain rules and restrictions must be followed to create a valid BWM class hierarchy: 

□ Each traffic flow can only belong to one bandwidth management class. 
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You can classify multiple flows into the same bandwidth class, but any given flow is always 
counted as belonging to a single class. If multiple policy rules match a single flow and try to 
classify it into multiple bandwidth classes, the last classification done by policy applies. 

□ When a flow is classified as belonging to a bandwidth class, all packets belonging to that flow is 
counted against that bandwidth class. 

□ If a minimum bandwidth is configured for a parent class, it must be greater than or equal to the 
sum of the minimum bandwidths of its children. 

□ If a maximum bandwidth is configured for a parent class, it must be greater than or equal to the 
largest maximum bandwidth set on any of its children. It must also be greater than the sum of the 
minimum bandwidths of all of its children. 

□ The minimum bandwidth available to traffic directly classified to a parent class is equal to its 
assigned minimum bandwidth minus the minimum bandwidths of its children. For example, if a 
parent class has a minimum bandwidth of 600 kbps and each of its two children have minimums 
of 300 kbps, the minimum bandwidth available to traffic directly classified into the parent class 
is 0. 

Relationship among Minimum, Maximum, and Priority Values 

Maximum values can be used to manage bandwidth for classes whether or not they are placed into a 
hierarchy. This is not true for minimums and priorities, which can only manage bandwidth for classes 
that are placed into a hierarchy. Additionally, a hierarchy must have a maximum configured on a 
high-level parent class in order for the minimums and priorities to manage bandwidth. 

This is because, without a maximum, bandwidth goes to classes without limit and there is no point to 
setting priorities or minimum guarantees. Bandwidth cannot be managed unless a maximum limit is 
set somewhere in the hierarchy. 

When a hierarchy has a maximum on the top-level parent and minimums, maximums and priorities 
placed on the classes related to that parent, the following conditions apply: 

□ If classes in a hierarchy have minimums, the first thing that happens with available bandwidth is 
that all the minimum requests are satisfied. If the amount requested is less than the minimum for 
any class, it receives the entire amount, and its priority level does not matter. 

Keep in mind that, even though a minimum is considered to be a guaranteed amount of 
bandwidth, satisfying minimums is dependent on the parent being able to receive its own 
maximum, which is not guaranteed. 

□ When all of the classes in a hierarchy have had their minimums satisfied, any additional requests 
for bandwidth must be obtained. When a class requests more than its minimum, it must obtain 
bandwidth from its parent or one of its siblings. If, however, a class requests more than its 
maximum, that request is denied — no class with a specified maximum is ever allowed more than 
that amount. 

□ If a class does not have a minimum specified, it must obtain all of the bandwidth it requests from 
its parents or siblings, and it cannot receive any bandwidth unless all of the minimums specified 
in the other classes in its hierarchy are satisfied. 
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□ Classes obtain bandwidth from their parents or siblings based on their priority levels — the highest 
priority class gets to obtain what it needs first, until either its entire requested bandwidth is 
satisfied or until it reaches its maximum. After that, the next highest priority class gets to obtain 
bandwidth, and this continues until either all the classes have obtained what they can or until the 
maximum bandwidth available to the parent has been reached. The amount available to the 
parent can sometimes be less than its maximum, because the parent must also participate in 
obtaining bandwidth in this way with its own siblings and/or parent if it is not a top-level class. 

Flow Classification 

You can classify flows to BWM classes by writing policy rules that specify the bandwidth class that a 

particular traffic flow belongs to. A typical transaction has four traffic flows: 

1. Client inbound — traffic flowing into the ProxySG from a client (the entity sending a request, such 
as a client at a remote office linked to the ProxySG). 

2. Server outbound — traffic flowing out of the ProxySG to a server. 

3. Server inbound — traffic flowing back into the ProxySG from a server (the entity responding to the 
request). 

4. Client outbound — traffic flowing back out of the ProxySG to a client. 

Figure 10-1 shows the traffic flows between a client and server through the ProxySG. 



Oci> er| t Inbound 



^ Server Outbound 




Client 



Q Client Outbound 



@ Server Inbound 



Server 



Figure 10-1 : Network Configuration Showing Traffic Flow Directions 

Some types of traffic can flow in all four directions. The following example describes different 
scenarios that you might see with an HTTP request. A client sends a GET to the ProxySG (client 
inbound). The ProxySG then forwards this GET to a server (server outbound). The server responds to 
the ProxySG with the appropriate content (server inbound), and then the ProxySG delivers this 
content to the client (client outbound). 

Policy allows you to configure different classes for each of the four traffic flows. See "Using Policy to 
Manage Bandwidth" on page 500 for information about classifying traffic flows with policy. 
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Configuring Bandwidth Allocation 

You can use either the Management Console or the CLI to do the following tasks: 

□ Enable or disable bandwidth management. 

□ Create and configure bandwidth classes. 

□ Delete bandwidth classes. 

□ View bandwidth management class configurations. 



Note: If you are planning to manage the bandwidth of streaming media protocols (Windows 

Media, Real Media, or QuickTime), you might want to use the streaming features instead 
of the bandwidth management features described in this section. For most circumstances. 
Blue Coat recommends that you use the streaming features to control streaming 
bandwidth rather than the bandwidth management features. For information about the 
differences between these two methods, see "Choosing a Method to Limit Streaming 
Bandwidth” on page 742. 



Enabling or Disabling Bandwidth Management 

The following procedures explain how to enable or disable bandwidth management through the 
Management Console or the CLI. 

To Enable or Disable Bandwidth Management through the Management Console 
1. Select Configuration>Bandwidth Management>BWM Classes>Bandwidth Classes. 

Bandwidth Classes 

0 Enable Bandwidth Management 

[-Bandwidth Classes 




J New | [ Edit | | Delete | 

Apply ][ Cancel ]( Help 

Figure 10-2: Bandwidth Classes Tab 

2. To enable or disable bandwidth management, select or deselect the Enable Bandwidth Management 
checkbox. 
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3. Click Apply. 

To Enable or Disable Bandwidth Management through the CLI 

At the (conf ig) command prompt, enter the following commands to enable or disable bandwidth 
management: 

SGOS# (config) bandwidth-management 

SGOS# (config bandwidth-management) enable | disable 

Creating and Editing Bandwidth Classes 

The following procedures detail how to create and edit a bandwidth management class. 

To Create a BWM Class through the Management Console 

1. Select Configuration>Bandwidth Management>BWM Classes>Bandwidth Classes. 

2. To create a new BWM class, click New. 

The Create Bandwidth Class dialog displays. 



Create Bandwidth Class 




OK Cancel 



Figure 10-3: Create Bandwidth Class Dialog 
3. Fill in the fields as appropriate: 

• Class name: Assign a meaningful name for this class. The name can be up to 64 characters 
long; spaces are not allowed. 

• Parent: If you want the class you are creating to be the child of another class in the bandwidth 
class hierarchy, select a class from the Parent drop-down list. This class must already exist. 

• Min. Bandwidth: To set a minimum bandwidth for this class in kilobits per second (kbps), select 
Min. Bandwidth and enter a minimum bandwidth value in the field. The default minimum 
bandwidth setting is Unspecified, meaning the class is not guaranteed a minimum amount of 
bandwidth. 

• Max. Bandwidth: To set a maximum bandwidth for this class in kbps, select Max. Bandwidth and 
enter a maximum bandwidth value in the field. The default maximum bandwidth setting is 
Unlimited, meaning the class is not limited to a maximum bandwidth value by this setting. 

• Priority: Select a priority level for this class from the Priority drop-down list — 0 is the lowest 
priority level and 7 is the highest. The default priority is 0. 
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4. Click OK. 

5. Click Apply. 

To Create a BWM Class through the CLI 

1. At the (config) command prompt, enter the following commands to create a new BWM class: 
SGOS# (config) bandwidth-management 

SGOS# (config bandwidth-management) create bwm_class 
where bwm_class is the name of the new BWM class. 

2. Configure the newly created bandwidth class (see "To Edit a BWM Class through the CLI" on 
page 498 for instructions). 

To Edit a BWM Class through the Management Console 

1. Select Configuration>Bandwidth Management>BWM Classes>Bandwidth Classes. 

2. Highlight the class that you want to edit and click Edit. 

The Edit Class dialog displays. 



Edit Class Office_A 




OK | Cancel | 

Figure 10-4: Edit Class Dialog 

3. Fill in the fields as appropriate: 

• Class Name: this field cannot be edited. To change the name of a class, you must delete the 
class and create a new one with the new name. 

• Parent: To make the class you are editing be the child of another class in the bandwidth class 
hierarchy, select a class from the Parent drop-down list. 

• Min. Bandwidth: To set a minimum bandwidth for this class in kilobits per second (kbps), select 
Min. Bandwidth and enter a minimum bandwidth value in the field. The default minimum 
bandwidth setting is Unspecified, meaning the class is not guaranteed a minimum amount of 
bandwidth. 

• Max. Bandwidth: To set a maximum bandwidth for this class in kbps, select Max. Bandwidth and 
enter a maximum bandwidth value in the field. The default maximum bandwidth setting is 
Unlimited, meaning the class is not limited to a maximum bandwidth value by this setting. 

• Priority: Select a priority level for this class from the Priority drop-down list — 0 is the lowest 
priority level and 7 is the highest. The default priority is 0. 

4. Click OK. 
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5. Click Apply. 

To Edit a BWM Class through the CLI 

1. To set the priority level and minimum/maximum bandwidth values for an existing BWM class, 
enter the following commands: 

SGOS# (config) bandwidth-management 

SGOS# (config bandwidth-management) edit bwm_class 

This changes the prompt and puts you into the Bandwidth-Class submode. 

SGOS# (config bw-class bwm_class) min-bandwidth minimum_in_kbps 
SGOS# (config bw-class bwm_class) max-bandwidth maximum_in_kbps 
SGOS# (config bw-class bwm_class ) priority value_from_0_to_7 



where: 



min-bandwidth 


minimum in kbps 


Sets the minimum bandwidth for this class 
in kilobits per second. The default for this 
setting is unspecified, meaning that the 
class is not guaranteed a minimum 
amount of bandwidth. 


max-bandwidth 


maximum in kbps 


Sets the maximum bandwidth for this class 
in kilobits per second. The default for this 
setting is unlimited (no maximum). 


priority 


value from 0 to 7 


Sets the priority level for this class — 0 is 
the lowest priority level and 7 is the 
highest. The default priority is 0. 



2. (Optional) To reset the values to the defaults, enter the following commands: 

SGOS# (config bandwidth-management bwm_class ) no {min-bandwidth | 
max -bandwidth} 

where : 



no min-bandwidth 


Sets the default minimum to the default, unspecified (no minimum 
bandwidth guarantee). 


no max-bandwidth 


Sets the maximum-bandwidth setting to the default, unlimited (no 
maximum). 



3. To make this class a child of another class or to clear the parent class from this class, enter one of 
the following commands: 

SGOS# (config bandwidth-management bwm_class ) parent parent_class_name 
-or- 

SGOS# (config bandwidth-management bwm_class ) no parent 

4. To view the configuration for this class, enter the following command: 

SGOS# (config bandwidth-management bwm_class) view 

For example: 
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SGOS# (config bandwidth-management Office_A) view 



Class Name: 

Parent : 

Minimum Bandwidth: 
Maximum Bandwidth: 
Priority : 



Of f ice_A 
<none> 
unspecified 
750 kbps 
0 



5. To view the configuration of any child classes of this class, enter the following command: 
SGOS# (config bandwidth-management bwm_class ) view children 



Deleting a Bandwidth Management Class 



The following procedures explain how to delete a bandwidth management class through the 
Management Console or the CLI. 



Note: You cannot delete a class that is referenced by another class or by the currently installed 

policy. For instance, you cannot delete a class that is the parent of another class or one that 
is used in an installed policy rule. If you attempt to do so, a message displays explaining 
why this class cannot be deleted. 



To Delete a BWM Class through the Management Console 

1. Select Configuration>Bandwidth Management>BWM Classes>Bandwidth Classes. 

2. Highlight the class you want to delete and click the Delete button. 

The Remove Object dialog displays. 

3. Click Yes to delete the class. 

4. Click Apply. 

To Delete a BWM Class through the CLI 

At the (config) command prompt, enter the following command to delete the specified BWM class: 
SGOS# (config) bandwidth-management 

SGOS# (config bandwidth-management) delete bwm_class 

Viewing Bandwidth Management Configurations and Statistics 

You can view bandwidth management configurations to see what the settings are for each class, and 
you can view bandwidth management statistics to see the current and total bandwidth, packet rate, 
and number of drops (the total number of packets dropped). 

Bandwidth management configurations (minimum / maximum bandwidth, priority level, and 
hierarchy relationships) are visible in the Management Console. The view commands allow you to 
view the same information in the CLI. See "Bandwidth Management Statistics" on page 1010 for 
information about viewing bandwidth management statistics. 

Viewing Bandwidth Management Configurations 

You can view the following bandwidth class configurations through the Management Console or CLI 
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□ Level in the hierarchy (parent /child relationships) 

□ Priority level 

□ Maximum bandwidth value 

□ Minimum bandwidth value 

To View BWM Configuration through the Management Console 

1. Select Configuration>Bandwidth Management>BWM Classes>Bandwidth Classes. 

On this tab, you can view a class's minimum, maximum and priority value. Top level classes are 
visible — classes with children have a folder icon on the left. 

2. To view the configurations of the child class(es) of a class, double-click the folder icon. 

The child classes become visible. A second double-click closes the folder. 

To View BWM Configuration through the CLI 

1. To view all BWM configuration information, enter the following commands at the (conf ig) 
command prompt: 

SGOS# (config) bandwidth-management 

SGOS# (config bandwidth-management) view configuration 

2. To view the BWM configuration for a specific class, enter the following command: 

SGOS# (config bandwidth-management) view configuration bwm_class 

For example: 

SGOS# (config bandwidth-management) view configuration Office_A 
Class Name: Office_A 

Parent : <none> 

Minimum Bandwidth: unspecified 

Maximum Bandwidth: 750 kbps 

Priority: 0 

3. To view the BWM configuration for the children of a specific class, enter the following commands: 

SGOS# (config bandwidth-management) edit bwm_class 
SGOS# (config bw-class bwm_class) view children 

Viewing Bandwidth Management Statistics 

See "Bandwidth Management Statistics" on page 1010 for information about viewing BWM statistics. 

Using Policy to Manage Bandwidth 

Once you have created and configured bandwidth management classes, you need to create policy 
rules to classify traffic flows using those classes. Each policy rule can only apply to one of four traffic 
flow types: 

□ Client inbound 

□ Client outbound 

□ Server inbound 
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□ Server outbound 

You can use the same bandwidth management classes in different policy rules, so that one class can 
manage bandwidth for several types of flows based on different criteria. However, any given flow is 
always be counted as belonging to a single class. If multiple policy rules match a flow and try to 
classify it into multiple bandwidth classes, the last classification done by policy will apply. 

To manage the bandwidth classes you have created, you can either compose CPL (see "CPL Support 
for Bandwidth Management" below) or you can use VPM (see "VPM Support for Bandwidth 
Management" on page 501). To see examples of policy using these methods, see "Bandwidth 
Allocation and VPM Examples" on page 502 or "Policy Examples: CPL" on page 509. 

CPL Support for Bandwidth Management 

You must use policy to classify traffic flows to different bandwidth classes. Refer to the Blue Coat 
ProxySG Content Policy Language Guide for more information about writing and managing policy. 

CPL Triggers 

You can use all of the CPL triggers for BWM classification (refer to the Blue Coat ProxySG Content Policy 
Language Guide for information about using CPL triggers). Basing a bandwidth decision on a trigger 
means that the decision does not take effect until after the information needed to make that decision 
becomes available. For example, if you set the CPL to trigger on the MIME type of the HTTP response, 
then the HTTP headers must be retrieved from the OCS before a classification can be made. The 
decision to retrieve those headers is made too late to count any of the request bytes from the client or 
the bytes in the HTTP response headers. However, the decision affects the bytes in the body of the 
HTTP response and any bytes sent back to the client. 

Supported CPL 

Bandwidth class can be set with policy on each of these four traffic flows: 

□ limit_bandwidth . client . inbound (none | bwm_class) 
n limit_bandwidth . client . outbound (none | bwm_class) 

□ limit_bandwidth . server . inbound (none | bwm_class ) 
n limit_bandwidth . server . outbound (none | bwm_class ) 

If you set policy to none, the traffic is unclassified and is not to be bandwidth-managed. 

VPM Support for Bandwidth Management 

You can manage bandwidth using VPM in the Action column of four policy layers: Web Access, DNS 
Access, Web Content, and Forwarding Layers. For more information about using VPM to manage 
bandwidth, see "Manage Bandwidth” on page 645. For examples of bandwidth management scenarios 
using VPM, see "Bandwidth Allocation and VPM Examples" below. 
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Bandwidth Allocation and VPM Examples 

This section illustrates how to allocate bandwidth, arrange hierarchies, and create policy using the 
Visual Policy Manager. It describes an example deployment scenario and the tasks an administrator 
must accomplish to manage the bandwidth for this deployment. For specific instructions about 
allocating bandwidth through either the Management Console or the CLI, see "Configuring 
Bandwidth Allocation" on page 495. For examples of bandwidth management tasks done by 
composing CPL, see "Policy Examples: CPL" on page 509. 

Task One: Bandwidth Allocation 

The administrator is responsible for managing the bandwidth of three branch offices. He has been told 
to make sure that each office uses no more than half of its total link bandwidth for Web and FTP 
traffic. The total link bandwidth of each office is as follows: 

□ Office A: 1.5 Mb 

□ Office B: 1 Mb 

□ Office C: 2 Mb 

He creates one bandwidth class for each of the three offices and configures the maximum bandwidth 
to an amount equal to half of the total link bandwidth of each, as shown in Figure 10-5. He also creates 
policy rules for each class, as described below in "Task One: VPM”. 




Figure 10-5: Bandwidth Hierarchy Diagram One 

Each of the classes in Figure 10-5 has a maximum set at an amount equal to half of the total link 
bandwidth for each office. A hierarchy does not exist in this scenario. 

Task One: VPM 

The administrator has created one bandwidth class for each office, setting a maximum bandwidth on 
each one equal to the half of the total link bandwidth of each. Now he must create policy rules to 
classify the traffic flows. 

The administrator launches VPM and creates a new Web Access Layer, calling it FTP/HTTP 
Limitations. He selects the Client IP Address/Subnet object in the Source column, filling in the IP 
address and mask of the subnet used by Office_A, as shown in Figure 10-6. 
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Figure 10-6: Adding the Client IP Address and Subnet Mask to the Source Column 

He selects a Combined Service Object in the Service column, naming it FTP/HTTP and adding a Client 
Protocol for FTP and for HTTP. In the Add Combined Service Object dialog, he adds both protocols to 
the top box, as shown in Figure 10-7. 




Figure 10-7: Adding Protocols to a Combined Service Object 

In the Action column, he selects Manage Bandwidth, naming it Office_A and setting it to manage the 
bandwidth of Office_A on the Client side in the Outbound direction, as shown in Figure 10-8. 



503 





Blue Coat Proxy SG Configuration and Management Guide 




Figure 10-8: Manage Bandwidth Action Object 

He adds two more similar rules for the other two offices. He is able to reuse the same Combined Service 
Object in the Service column, but must add new objects specific to each office in the Source and Action 
columns. The order of the rules does not matter here, because each office, and thus each rule, is 
distinct because of its IP address / subnet mask configuration. 

Task Two: Bandwidth Allocation 

A few days later, the administrator gets a visit from the CEO of his company. She wants him to fix it so 
that she can visit any of the branch offices without having her own Web and FTP access slowed down 
unnecessarily. 

The administrator creates two more classes for each office: one for the CEO and another for everyone 
else (employees). He sets the parent class of each new class to the appropriate class that he created in 
Task One. For instance, he creates Emp_A and CEO_A and sets their parent class to Office_A. He also 
sets a priority level for each class: 0 (the lowest) for employees and 1 for the CEO. He then uses VPM 
to create additional policy rules for the new classes (see "Task Two: VPM" below). Figure 10-9 shows 
the hierarchical relationship among all of the classes. 




Figure 10-9: Bandwidth Hierarchy Diagram Two 

The administrator now has three separate hierarchies. In each one, bandwidth is limited by the 
configuration of the parent class, and the two child classes are prioritized to determine how they share 
any unused bandwidth. Because no minimums have been set, the highest priority class has the first 
opportunity to use all of the available bandwidth; whatever is left then goes to the next priority class. 

Priority levels are only effective among the classes in the same hierarchy. This means that the priority 
levels for the Office_A hierarchy do not affect the classes in the Office_B or Office_C hierarchies. 
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Task Two: VPM 

Because the CEO wants to prioritize FTP and HTTP access among employees and herself, the 
administrator must create additional bandwidth classes (as described above in "Task Two: Bandwidth 
Allocation") and write policy rules to classify the traffic for the new classes. 




He first edits each of the three VPM rules for the three offices. He edits each the Manage Bandwidth 
objects, changing the name of the objects to Emp_A, Emp_B, and Emp_C and changes the bandwidth 
class to the corresponding employee class (see Figure 10-10). 






Figure 10-10: Editing the Bandwidth Management Object 

Next, he creates three more rules for the CEO, moving them above the first three rules. For the CEO 
rules, he selects the same combined FTP/HTTP object in the Service column; in the Action column, he 
selects a Manage Bandwidth object configured for client side/outbound, as before, but this time, he 
names the objects CEO_A, CEO_B, and CEO_C and selects the corresponding CEO bandwidth class. In 
the Source column, he creates a Combined Source Object, naming it for the CEO. He combines the Client 
I P/subnet object already created for each office with a User object that he creates for the CEO, as shown 
in Figure 10-10. 
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Figure 10-11: Adding a Combined Source Object 

The administrator places all three CEO rules above the employee rules, because the ProxySG looks for 
the first rule that matches a given situation and ignores the remaining rules. If he had placed the CEO 
rules below the employee rules, the ProxySG would never get to the CEO rules because the CEO's 
Web surfing client IP address matches both the CEO rules and the employee rules, and the ProxySG 
would stop looking after the first match. With the CEO rules placed first, the ProxySG applies the CEO 
rules to the CEO's Web surfing, and an employee's Web surfing does not trigger the CEO rules and 
instead skips ahead to the appropriate employee rule. 

Task Three: Bandwidth Allocation 

It soon becomes apparent that CEO visits are causing problems for the branch offices. At times, she 
uses all of the available bandwidth, resulting in decreased productivity throughout the office she 
visits. Also, management has complained that they have been given the same priority for FTP and 
HTTP traffic as regular employees, and they are requesting that they be given priority over employees 
for this type of traffic. 

First, the administrator creates two new classes for each office. In this example, we will look at the 
classes and configurations for the first office only. He creates a class called Staff_A and sets a minimum 
bandwidth of 500 kbps on it. He also creates a class called Mgmt_A, setting the priority to 1 and the 
parent to Staff_A. He edits the class Emp_A, setting the parent to Staff_A. Finally, he edits the class 
CEO_A, changing the priority to 2. The resulting hierarchy is illustrated in Figure 10-12. To see what 
the administrator did to the policy rules, see "Task Three: VPM" below. 
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Figure 10-12: Bandwidth Hierarchy Diagram Three 



In the example illustrated above, employees and management combined are guaranteed a total of 500 
kbps. The CEO's priority level has no effect until that minimum is satisfied. This means that the CEO 
can only use 250 kbps of bandwidth if the rest of the staff are using a total of 500 kbps. It also means 
that the CEO can use 750 kbps if no one else is using bandwidth at the time. In fact, any of the classes 
can use 750 kbps if the other classes use none. 

Priority levels kick in after all of the minimums are satisfied. In this example, if the staff requests more 
than 500 kbps, they can only receive it if the CEO is using less than 250 kbps. Now notice that the 
minimum setting for the staff is set on the parent class, Staff_A, and not on the child classes, Emp_A or 
Mgmt_A. This means that the two child classes, representing employees and management, share a 
minimum of 500 kbps. But they share it based on their priority levels. This means that management 
has priority over employees. The employees are only guaranteed a minimum if management is using 
less than 500 kbps. 

Task Three: VPM 

The administrator has added additional classes for each office and edited the existing employee 
classes, as described above in "Task Three: Bandwidth Allocation". One of the new classes he added 
for each office is a parent class that does not have traffic classified to it; it was created to provide a 
minimum amount of bandwidth to its child classes. Not every class in the hierarchy has to have a 
traffic flow. This means that he needs to add just three more rules for the three new management 
classes. For the management rules, he selects the same combined FTP/HTTP object in the Service 
column; in the Action column, he selects a Manage Bandwidth object configured for client side/outbound 
with the bandwidth class one of the management classes (Mgmt_A, Mgmt_B, or Mgmt_C). In the Source 
column, he creates a Combined Source Object containing the subnet object for the office and the Group 
object for management. 

The management rules must go above the employee rules, although it does not matter where they are 
placed in relation to the CEO rules. This would not be true if the CEO was part of the same group as 
management, however. If that were true, the CEO rules would still need to go on top. 

Task Four: Bandwidth Allocation 

The administrator decided later that he needed to guarantee employees some bandwidth. He 
configures a minimum for the class Emp_A, as illustrated in Figure 10-13. 
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Figure 10-13: Bandwidth Hierarchy Diagram Four 



He decides to leave the minimum on the parent class Staff_A and not to set a minimum for the class 
Mgmt_A. This is okay, because the minimum of the parent class is available to its children if the parent 
class does not use all of it, and the only way that the CEO can get more than 250 kbps is if the 
employees and management combined use less than 500. 

This last change does not require additional changes to policy; the administrator has added a 
minimum to a class that he has already classified for traffic using policy. 

In the above scenario, the class called Staff_A does not have traffic configured for it — it was created to 
guarantee bandwidth minimums for its child classes. However, if it were configured for traffic, it 
would have a practical minimum of 300 kbps. The practical minimum of a parent class is equal to its 
assigned minimum bandwidth minus the minimums of its children. In that case, if the parent class 
Staff_A used 300 kbps and the child class Emp_A used 200 kbps, the child class Mgmt_A would not 
receive any bandwidth unless the class CEO_A was using less than 250 kbps. Under those 
circumstances, the administrator probably also needs to create a minimum for management. 

Task Five: Bandwidth Allocation 

The CEO makes another request, this time for the main office, the one the administrator himself works 
from. This office uses the content filtering feature of the ProxySG to control the types of Web sites that 
employees are allowed to view. Although the office uses content filtering, access to sports sites is not 
restricted because the CEO is a big fan. 

The administrator creates a bandwidth management class called Sports with a maximum bandwidth 
of 500 kbps and launches VPM to create policy for this class as described below. 

Task Five: VPM 

To classify traffic for the Sports class, the administrator opens VPM, creates a Web Access Layer, and 
sets the Destination column to the Category object that includes sports viewing (content filtering is 
already set up in VPM). He sets the Action column to the Manage Bandwidth object, selecting Server 
side/inbound and the Sports bandwidth class he created. After installing the policy and verifying that 
bandwidth management is enabled, he is finished. 
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Policy Examples: CPL 

The examples below are complete in themselves. The administrator uses CLI to create and configure 
bandwidth management classes and writes CPL to classify traffic flow for these classes. These 
examples do not make use of a bandwidth class hierarchy. For examples of hierarchies, see 
"Bandwidth Allocation and VPM Examples" on page 502. 

Example One: CPL 

In this example, the administrator of a college is asked to prevent college students from downloading 
MP3 files during peak hours, while still allowing the music department to download MP3 files at any 
time. The CPL triggers used are authentication and/or source subnet and MIME type. The action 
taken is to limit the total amount of bandwidth consumed by students to 40 kbps. 

CLI commands: 

SGOS# (config) bandwidth-management 

SGOS# (config bandwidth-management) create mp3 
SGOS# (config bandwidth-management) edit mp3 
SGOS# (config bw-class mp3) max-bandwidth 40 

CPL: 

define condition student_mp3_weekday 

cl ient_address= st udent_sub.net response_header . Content -Type= " audio/mpeg" \ 
weekday=l . . 5 hour=9 . . 16 
end condition 

<proxy> 

condi tion=student_mp3_weekday limit_bandwidth . server . inbound (mp3 ) 

Example Two: CPL 

In this example, an administrator must restrict the amount of bandwidth used by HTTP POST 
requests for file uploads from clients to 2 Mbps. The CPL trigger used is request method, and the 
action taken is to throttle (limit) the amount of bandwidth used by client side posts by limiting 
inbound client side flows. 

CLI commands: 

SGOS# (config) bandwidth-management 

SGOS# (config bandwidth-management) create http post 
SGOS# (config bandwidth-management) edit http_post 
SGOS# (config bw-class http_post) max-bandwidth 2000 

CPL: 

define condition http_posts 
http . method=POST 
end condition 

<proxy> 

condition=http_posts limit_bandwidth. client . inbound (http_post) 
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Example Three: CPL 

In this example, the administrator of a remote site wants to limit the amount of bandwidth used to 
pre-populate the content from headquarters to 50 kbps during work hours. The CPL triggers used are 
current-time and pre-population transactions. The action taken is to limit the total amount of 
bandwidth consumed by pre-pop flows. 

CLI commands: 

SGOS# (config) bandwidth-management 

SGOS# (config bandwidth-management) create pre-pop 
SGOS# (config bandwidth-management) edit pre-pop 
SGOS# (config bw-class pre-pop) max-bandwidth 50 

CPL: 

define condition prepop_weekday 

content_management=yes weekday=1..5 hour=9..16 
end condition 

<proxy> 

condition=prepop_weekday limit_bandwidth . server . inbound (pre-pop) 
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This chapter describes how to configure the ProxySG to interact with external ICAP and Websense 

servers to provide content scanning, content transformation, and content filtering services. 

This chapter contains the following sections: 

□ "Section A: ICAP” — Describes the ICAP protocol and describes how to create and manage ICAP 
services and patience pages on the ProxySG. 

n "Section B: Websense" — Describes how to create a Websense service 

□ "Section C: Service Groups" — Describes how to create service groups of ICAP or Websense entries 
and configure load balancing. 

n "Section D: Displaying External Service and Group Information” — Describes how to display 
external service configurations through the CLI. 

Related Topics: 

□ Appendix 12: "Health Checks" 

□ Appendix 18: "Content Filtering” 
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Section A: ICAP 

Section A: ICAP 

This section describes the Internet Content Adaptation Protocol (ICAP) solution of content scanning 
and modification. 

When integrated with a supported ICAP server, the ProxySG provides content scanning, filtering, and 
repair service for Internet-based malicious code. ICAP is an evolving architecture that allows an 
enterprise to dynamically scan and change Web content. To eliminate threats to the network and to 
maintain caching performance, the ProxySG sends objects to the integrated ICAP server for checking 
and saves the scanned objects in its object store. With subsequent content requests, the appliance 
serves the scanned object rather than rescan the same object for each request. 

Configuring ICAP on the ProxySG involves the following steps: 

1. Install the ICAP server. 

2. Configure the ProxySG to use ICAP and configure basic features. 

3. Define scanning policies, then load the policy file on the ProxySG. 

Supported ICAP Servers 

The Blue Coat ProxySG with ProxyAV™ integration is a high-performance Web anti-virus (AV) 
solution. 

The ProxySG also supports the following ICAP third-party ICAP implementations: 

□ Symantec AntiVirus Scan Engine (SAVSE) 

□ WebWasher 

□ Finjan Vital Security for Web 

For the most current list of vendors and supported versions, refer to the Blue Coat ProxySG Release 
Notes for this release. 

ICAP vl.O Features 

This section describes features of the ICAP vl.O protocol. 

Sense Settings 

The Sense Settings feature allows the ProxySG to query any identified ICAP server running vl.O, 
detect the parameters, and configure the ICAP service as appropriate. See "Creating an ICAP Service" 
on page 515. 

ISTags 

An ICAP vl.O server is required to return in each response an ICAP header ISTag indicating the 
current state of the ICAP server. This eliminates the need to designate artificial pattern version 
numbers, as is required in v0.95. 
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Note: Backing out a virus pattern on the ICAP server can revert ISTags to previous values that 

are ignored by the ProxySG. To force the ProxySG to recognize the old value, use the 
Sense Settings option as described in "Creating an ICAP Service" on page 515. 



Persistent Connections 

New ICAP connections are created dynamically as ICAP requests are received (up to the defined 
maximum connection limit). The connection remains open to receive further requests. If a connection 
error occurs, the connection closes to prevent further errors. 

About Content Scanning 

The ProxySG ICAP scanning solution prevents the spread of viruses and other malicious code by 
serving content that has been scanned by a supported ICAP server. 

Determining Which Files to Scan 

In determining which files to scan, this integrated solution uses the content scanning server's filtering 
in addition to ProxySG capabilities. Table 11.1 describes the supported content types and protocols. 



Table 11.1: Content Types Scanned By ICAP Server and the ProxySG 



ICAP Server 

supported content types 


ProxySG 

supported protocols 


Unsupported content 
protocols 


All or specified file types, based 
on file extension, as configured 
on the server. 

Examples: . exe (executable 
programs), . bat (batch 
files), .doc and .rtf 
(document files), and . zip 
(archive files), or with specific 
MIME types. 


• HTTP objects 

• FTP objects (uploads and 
downloads) 

• Transparent FTP responses 


• Streaming content (for example, 
RTSP and MMS) 

• Live HTTP streams (for example, 
HTTP radio streams) 




HTTPS connections terminated at 
a ProxySG. 


HTTPS connections tunneled through 
a Blue Coat client-side ProxySG. 



After the ProxySG retrieves a requested Web object from the origin server, it uses content scanning 
policies to determine whether the object should be sent to the ICAP server for scanning. If cached 
objects are not scanned or are scanned before a new pattern file was updated, the ProxySG rescans 
those objects upon: 

□ the next request for that object, or 

□ the object is refreshed. 
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With the ProxySG, you can define flexible, enterprise-specific content scanning policies. Consider the 
following example. A business wants to scan software downloaded by employees from popular 
shareware Web sites. To do this, the business defines an appliance policy that includes a custom 
scanshareware action for the purpose. This rule includes URL domains related to the relevant 
shareware Web sites. 

Before continuing, plan the types of policies you want to use. For more information, see "Creating 
ICAP Policy" on page 525. 

Performing Response Modification 

The ProxySG sends the first part (a preview) of the object to the ICAP server that supports response 
modification. The object preview includes the HTTP request and response headers, and the first few 
bytes of the object. After checking those bytes, the ICAP server either continues with the transaction 
(that is, asks the ProxySG to send the remainder of the object for scanning) or sends a notification to 
the appliance that the object is clean and opts out of the transaction. 

The ICAP server features and configuration determine how scanning works, including the following: 

□ Handling of certain objects, including those that are infected and cannot be repaired. 

□ Whether to attempt to repair infected files. 

□ Whether to delete infected files that cannot be repaired from the ICAP server's archive. 

Performing Request Modification 

The ProxySG sends the client request to a ICAP server that supports request modification. The server 
might then return an HTTP response to the client (for example, sports not allowed); or the client 
request might be modified, such as stripping a referer header, before continuing to the origin content 
server. 



Note: Some ICAP servers do not support virus scanning for request modification, only content 

filtering. 



Returning the Object to the ProxySG 

This object can be the original unchanged object, a repaired version of the original object minus a 
virus, or an error message indicating that the object contained a virus. Each of these responses is 
configured on the ICAP server, independent of the appliance and the ICAP protocol. If the appliance 
receives the error message, it forwards the error message to the client and does not save the infected 
file. 
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Caching and Serving the Object 

Once an object has been scanned and is determined cacheable, the ProxySG saves it and serves it for 
the subsequent content requests. When the appliance detects that the cached content has changed on 
the origin server, it fetches a fresh version, then forwards it to the ICAP server for scanning. If the 
ProxySG uses policies in the ICAP configuration, the policy applies to content fetches, distributes, and 
refreshes, as well as pipelining fetches. 

For more information on policies, see "Creating ICAP Policy" on page 525. For more information on 
the <Cache> layer, refer to the Blue Coat ProxySG Content Policy Language Guide. 

Installing the ICAP Server 

Follow the manufacturer instructions for installing the ICAP server, including any configuration 
necessary to work with the Blue Coat ProxySG. Based on your network environment, you might use 
the ProxySG with multiple ICAP servers or multiple scanning services on the same server. Configure 
options as needed, including the error message displayed to end users in the event the requested 
object was modified or blocked. 

Creating an ICAP Service 

An ICAP service on the ProxySG is specific to the ICAP server and includes the server IP address or 
hostname, as well as the supported number of connections. If you are using the ProxySG with 
multiple ICAP servers or multiple scanning services on the same server, add an ICAP service for each 
server or scanning service. 

To Create and Configure an ICAP Service through the Management Console 

1. Select Configuration>External Services>ICAP Services. 

2. Click New; the Add List Item dialog appears. 

3. In the ICAP service name field, enter an alphanumeric name; click OK. 

4. Highlight the new ICAP service name and click Edit; the Edit ICAP Service dialog appears. 
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Edit ICAP Service test 






- Edit ICAP Service test 

ICAP version: j q v 

Service URL: | 

Maximum number of connections: 5 
Connection timeout (seconds): | 70 

Patience page delay (seconds): | 1 n | j— | ena bled 

Notify administrator: Q Vjrus det e C ted 

- ICAP v 1.0 Options 

Method supported: 0 res p 0nse modification 

O request modification 

Preview size (bytes): 0 [ 0 enabled 

Send: □ Client address □ Server address 

Authenticated user □ Authenticated groups 

ICAP server tag: 

I Sense settings | Get settin 9 s from ICAP server 

- Health Check Options 

Register | Register the service for health checks 

Health check I Perform a health check on this service 



OK ] ( Cancel j 

Figure 11-1: ICAP Service Dialog 

The default ICAP version is 1.0 and cannot be changed. 

5. Enter or select the following information: 

a. The service URL, which includes the URL schema, ICAP server hostname or IP address, 
and the ICAP port number. For example: 
icap : / /10 .x.x.x/ 

The default port number is 1344, which can be changed; for example: 

icap : //io . x . x . x : 99. You can also give an HTTP URL, but you must define a port 

number. 



1.0 v 

I 



Note: An ICAP service pointing to a WebWasher server must use icap as the protocol 

in the URL. Blue Coat also recommends that you review your specific ICAP 
server documentation, as each vendor might require additional URL information. 



516 




Chapter 1 1 : External Services 



Section A: ICAP 



b. The maximum number of connections possible at any given time between the ProxySG 
and the ICAP server. The range is a number from 1 to 65535. The default is 5. The number 
of recommended connections is dependent on the capabilities of the ICAP server. Refer to 
the vendor's product information. 

c. The number of seconds the ProxySG waits for replies from the ICAP server. The range is 
60 to 65536. The default timeout is 70 seconds. 

d. Optional: You can enable the ProxySG to display a default patience page when an ICAP 
server is processing a relatively large object. The page informs users that a content scan is 
in process. If enabled, the patience page is displayed after the designated time value is 
reached for scanned objects. 



Note: Patience pages display regardless of any pop-up blocking policy that is in effect. 



To enable the patience page, in the Patience page delay field, enter the number of seconds the 
ProxySG waits before displaying the page. The range is 5 to 65535. Select Enable. 

e. Select Notify administrator: Virus detected to send an e-mail to the administrator if the ICAP 
scan detects a virus. The notification is also sent to the Event Log and the Event Log 
e-mail list. 

6. The following steps configure ICAP vl.O features: 

a. Select the ICAP method: response modification or request modification. 



Note: An ICAP server might have separate URLs for response modification and request 

modification services. 



b. Enter the preview size (in bytes) and select preview size enable. The ICAP server reads the 
object up to the specified byte total. The ICAP server either continues with the transaction 
(that is, receives the remainder of the object for scanning) or opts out of the transaction. 

The default is 0. Only response headers are sent to the ICAP server; more object data is only 
sent if requested by the ICAP server. 

c. (Optional) Click Send: Client address or Server address to specify what is sent to the ICAP 
server: Send: Client address. Server address. Authenticated user, or Authenticated groups. 

d. (Optional) Clicking Sense Settings automatically configures the ICAP service using the 
ICAP server parameters. If you use the sense settings feature, no further steps are 
required; the ICAP service is configured. Otherwise, proceed with the manual 
configuration. 

7. Click OK; click Apply. 
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To Register a Newly Created ICAP Service for Health Checking: 

For convenience, the Edit ICAP Service dialog allows you to register a newly-created ICAP service for 
health checking (this duplicates the functionality on the Configuration>Health Checks>General tab). 
Registering for health checking requires that a valid ICAP server URL was entered. 

□ Click Register; a dialog prompts confirmation; click OK. 

□ You can also click Health check to perform an immediate health check on this service. 

To Monitor ICAP Health Checks 

In a browser, enter one of the following URLs to list health check information. 

□ To list all health check entries and their configuration parameters, enter: 
http : / /ProxySG_IP_address : 8081/health_check/view 

□ To list the statistics for all currently active entries, enter: 

http : / /ProxySG_IP_address : 8081/health_check/statistics 
For more information about health checks, see Chapter 12: "Health Checks" on page 545. 

To Create and Configure an ICAP Service through the CLI 

1. At the (config) command prompt, enter the following commands: 

SGOS# (config) external - services 

SGOS# (config external-services) create icap service_name 
Specify a unique alphanumeric name for each service. 

2. To configure the service, enter the following commands: 

SGOS# (config external - services ) edit service_name 
SGOS# (config icap service_name) url icap://url 

where url specifies the URL schema, ICAP server hostname or IP address, and the ICAP port 
number. The default port number is 1344. 



Note: While http : //url : 1344 is valid, an ICAP service pointing to a WebWasher server 

must use icap as the protocol in the URL. 



SGOS# (config icap service_name) max-conn number 

where number is the maximum number, from 1 to 65535, of connections the ICAP service 
uses to connect to the ICAP server. The default is 5. Blue Coat recommends that the 
setting not exceed 200 . 

SGOS# (config icap service_name) timeout timeout_seconds 

where timeout_seconds is the number of seconds, from 60 to 65535, the ProxySG waits for 
replies from the ICAP server. The default timeout is 7 0 seconds. 

SGOS# (config icap service_name) notify virus -detected 

Sends an e-mail to the administrator if the ICAP scan detects a virus. The notification is also 
sent to the Event Log and the Event Log e-mail list. 
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3. The following commands configure ICAP vl.O features: 

SGOS# (config icap service_name ) methods {REQMOD | RESPMOD} 

Specifies the ICAP service type: request modification or response modification. 



Note: On most ICAP servers, one URL is designated for response modification and one 

for request modification. 



SGOS# (config icap service_name ) preview-size bytes 

where number is the preview size in bytes. If specified, the ICAP server reads the object 
up to the specified byte total. The ICAP server either continues with the transaction (that 
is, receives the remainder of the object for scanning) or opts out of the transaction. 

The default is o. Only response headers are sent to the ICAP server; more object data is 
only sent if requested by the ICAP server. 

Optional: 

SGOS# (config icap service_name) send {client-address | server-address} 

Specifies to send the client IP address or the server IP address to the ICAP server. 

SGOS# (config icap service_name) send { authenticated-user | 
authenticated-groups } 

Specifies to send authenticated user and group information to the ICAP server. 

4. Optional: If the ICAP server is a version 1.0 server, you can use the sense -settings command to 
automatically configure the ICAP service using ICAP server parameters. Otherwise, proceed with 
the manual configuration in Step 3. To use the ICAP server parameters, enter the following 
command: 

SGOS# (config icap services service_name ) sense-settings 
The ICAP service is now configured. No further steps are required. 

5. Optional: You can enable the ProxySG to display a default patience page when an ICAP server is 
processing a relatively large object. The page informs users that a content scan is in process. If 
enabled, the patience page is displayed after the designated time value is reached for scanned 
objects. 

SGOS# (config icap services service_name) patience-page seconds 

where seconds is the duration before the patience page is displayed. The range is 5 to 65535. 
The default is disabled. 



Note: Patience pages display regardless of any pop-up blocking policy that is in effect. 
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Deleting an ICAP Service 

The following steps describe how to delete an ICAP service. 



Note: You cannot delete an ICAP service used in a ProxySG policy (that is, if a policy rule uses 

the ICAP service name) or that belongs to a service group. 



To Delete an ICAP Service through the Management Console 

1. Select Configuration>External Services>ICAP. 

2. Select the service to be deleted. 

3. Click Delete; click OK to confirm. 

4. Click Apply. 

To Delete an ICAP Service through the CLI 

At the (conf ig) prompt, enter the following commands: 

SGOS# (config) external - services 

SGOS# (config external-service) delete service_name 

Customizing ICAP Patience Text 

This section describes how to customize text displayed during ICAP scanning. 

Using the HTTP Patience Text 

The ProxySG allows you to customize the patience pages that are displayed when HTTP clients 
experience delays as Web content is scanned. You can customize the following patience page 
components: 

□ Header — Contains HTML tags that define what appears in the dialog title bar. This component 
also contains the <meta http-equiv> tag, which is used to specify a non-English character set. 
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Customize Patience Header 



.=151*1 



□ 



Custom Patience Header: 



|<title> Please be patient<7title> 

<meta http-equiv="content-type" content="text/html; charseM SO -8859-1 "> 



Ok 



Cancel | 



Figure 1 1 -2: Customizing the Header Component 

Summary — HTML and text that informs users that a content scan is occurring. 




Figure 1 1 -3: Customizing the Summary Component 

□ Details — Uses data to indicate scanning progress. The information includes the URL currently 
being scanned, the number of bytes processed, and the elapsed time of the scan 
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Customize Patience Details 






Custom Patience Details Message: 



|<table cellpadding="2" cellspacing="2" border="0" align="center"> A 

<tbody> 

<tr> 

<td valign="top" width="30^">URL:</td> 

<td valign="top">$(url)</td> 

</tr> 

<tr> 

<td valign="top" width="30^"> Progress: </td> 

<td valign="top">$(patience_progress]</td> 

</tr> 

<tr> H 



Ok | Cancel | 

Figure 1 1 -4: Customizing the Details Component 

□ Help — Displays instructions for users should they experience a problem with the patience page. 




Figure 1 1 -5: Customizing the Help Component 
All of these components are displayed on the patience page. 

To Customize ICAP Patience Text through the Management Console 

1. Select Configuration>External Services>ICAP>ICAP Patience Page. 

2. In the HTTP Patience Page Customization field, click Header, Summary, Details, or Help; the 
appropriate customize dialog appears. Customize the information as appropriate. 

3. Click OK; click Apply. 

Example 

The following example demonstrates customizing the message summary. 
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Figure 1 1 -6: Entering a Custom Summary Message 

To Customize ICAP Patience Text through the CLI 

At the (config) command prompt, enter the following commands: 

SGOS# (config) external - services 

SGOS# (config external-services) inline http icap-patience {details | header 
| help | javascript | summary} eof 



where: 



eof 


Specifies the end-of-file marker. After entering customized text, enter the 
end-of-file marker to end the customizing process. 


details 


The string that displays the progress of the content scanning. 


header 


The tile of the page. Appears in the dialog title bar. The default is: 
Please be patient 


help 


Clients with browsers that do not support automatic refresh must click a link 
to load the content after scanning is complete. The default is: 

If your browser does not support automatic refresh, click 
the following link to download the scanned object. 
Continue . 

Note: Closing this window terminates the download. 


summary 


The text message informing users that a content scan is occurring. The default 
is: 

Your request is being scanned for security purposes. 
Please be patient. 
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Example: 

SGOS# (config) external - services 

SGOS# (config external-services) inline http icap-patience summary eof 

Your request is experiencing a slight delay while it is scanned for malicious 
content or viruses. If the content is safe, you will receive the request. 

Please be patient, eof 

SGOS# (config external-services) 

Windows XP, Service Pack 2 Behavior 

With Windows XP, Microsoft is continually updating the security measures, which impacts how the 
ProxySG manages patience pages. 

□ Browsers running on Windows XP, Service Pack 2 (XP SP2), experience slightly different patience 
page behavior when pop-up blocking is enabled. 

• If pop-up blocking is not enabled, patience page behavior should be normal. 

• If pop-up blocking is enabled (the default), the ProxySG attempts to display the patience page 
in the root window. 

• If the download triggers an invisible Javascript window, the user can track the scanning 
progress with the progress bar at the bottom of the window; however, if other policy blocks 
Javascript active content, this bar is also not visible. 

□ If Internet Explorer blocks all downloads initiated by Javascript, the user must click the yellow 
alert bar to download the scanned object. 

□ Users experience two patience page responses for non-cacheable objects. 

Interactivity and Limitations 

□ When ICAP scanning is enabled and a patience page is triggered, a unique URL is dynamically 
generated and sent to the browser to access the patience page. This unique URL might contain a 
modified version of the original URL. This is expected behavior. 

□ Patience pages and exceptions can only be triggered by left-clicking a link. If a user right-clicks a 
link and attempt to save it, it is not possible to display patience pages. If this action causes a 
problem, the user might see browser-specific errors (for example, an Internet site not found); 
however, ICAP policy is still in effect. 

□ A patience page is not displayed if a client object request results in an HTTP 302 response and the 
ProxySG pipelines the object in the Location header. Once the ProxySG receives the client request 
for the object, the client enters a waiting state because a server-side retrieval of the object is 
already in progress. The wait status of the client request prevents the patience page from 
displaying. To prevent the ProxySG from pipelining these requests (which decreases 
performance) and retain the ability to provide a patience page, configure HTTP: 

#ProxySG (config) http no pipeline client redirects 

□ The status bar update does not work if it is disabled or if the Javascript does not have sufficient 
rights to update it. 
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□ Looping: Certain conditions cause browsers to re-spawn patience pages. For example, a site states 
it will begin a download in 10 seconds, initiates a pop-up download window, and returns to the 
root window. If the download window allows pop-ups, the patience page is displayed in another 
window. The automatic return to the root window initiates the download sequence again, 
spawning another patience page. If unnoticed, this loop could cause a system hang. The same 
behavior occurs if the user clicks the back button to return to the root window. For known and 
used download sites, you can create policy that redirects the page so that it doesn't return to the 
root window after a download starts. 

Using the FTP Patience Text 

The patience text displayed to FTP clients during an ICAP scan can be modified. 

To Customize ICAP Patience Text through the Management Console 

1. Select Configuration>External Services>ICAP>ICAP Patience Page. 

2. In the FTP Patience Page Customization field, click Summary; the Customize FTP Patience Text dialog 
appears. Customize the FTP client patience text. Customize the information as appropriate. 

3. Click OK; click Apply. 

To Customize ICAP Patience Text through the CLI 

At the (config) command prompt, enter the following commands: 

SGOS# (config) external - services 

SGOS# (config external-services) inline ftp icap-patience- text eof 

Creating ICAP Policy 

Defined ICAP policy dictates the anti-virus behavior for your enterprise. You can either use the Visual 

Policy Manager (VPM) or you can manually edit policy files. For more information on the VPM and 

defining policies, see Chapter 14: "The Visual Policy Manager" on page 567. 

Use the request . icap_service ( ) (request modification) or response . icap_service ( ) (response 

modification) properties to manage the ProxySG ICAP services. 

VPM Objects 

The VPM contains the following objects specific to AV scanning (linked to their descriptions in the 

VPM chapter). 



Table 11.2: VPM ICAP Objects 



Object 


Layer>Column 


"Virus Detected" 


Web Access>Service 


"ICAP Error Code" 


Web Access>Service 


"Return ICAP Patience Page" 


Web Access>Action 
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Table 11.2: VPM ICAP Objects 



Object 


Layer>Column 


"Set ICAP Request Service" 


Web Access>Action 


"Set ICAP Response Service" 


Web Content>Action 



Note: For CPL policy, refer to the Blue Coat ProxySG Content Policy Language Guide. 



Example ICAP Policy 

The following VPM example demonstrates the implementation of an ICAP policy that performs virus 
scanning on both client uploads (to prevent propagating a virus) and responses (to prevent the 
introduction of viruses). 

For this example: 

□ The ProxySG has configured ICAP services. The response service is corporateavl and the request 
service is corporateav2. 

□ The ProxyAV is the virus scanner and is configured to serve password-protected files. 

□ A group named IT is configured on the ProxySG. 

□ The IT group wants to be allowed to download password protected files, but deny everyone else. 

Procedure — To Perform Virus Scanning, Protecting Both the Server Side and Client Side 

1. In the VPM, select Policy>Web Access Layer. Name the layer RequestAV. 

2. Right-click the Action column; select Set. The Set Action Object dialog appears. 
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a. Select Set ICAP Request Service; the Add ICAP Request Service Object dialog appears. 

b. From the Use ICAP request service drop-down list, select corporateav2. 

c. Select Deny the client request. This prevents a client from propagating a threat. If a virus is 
found, the content is not uploaded. For example, a user attempts to post a document that 
has a virus. 




Figure 11-7: Specifying an ICAP Response Service Object 
d. Click OK; click OK again to add the object to the rule. 

RequestAV 



No. Source 


Destination Service 


Time 


Action Track 


Comm... 


1 Any 


Any |Any 


|Any 


ICAPRequestServicel None 


r=] 



Figure 1 1 -8: The Web Content Layer policy 



3. In the VPM, select Policy>Web Content Rule. Name the rule ResponseAV. 

4. Right-click the Action column; select Set. The Set Action Object dialog appears. 

a. Select Set ICAP Response Service; the Add ICAP Response Service Object dialog appears. 

b. From the Use ICAP response service drop-down list, select corporateavl . 

5. Select Deny the client request. This scans the responses for viruses before the object is delivered to 
the client. If a virus is found, the content is not served. 

Procedure — To Log a Detected Virus 

1. In the VPM, select Policy>Web Access Layer. Name the layer AVErrors. 

2. Right-click the Service column; select Set. The Set Service Object dialog appears. 

a. Select Virus Detected (static object). 

b. Click OK to add the object to the rule. 

3. Right-click the Action column. Select Delete. 
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4. Right-click the Track column. Select Set; the Set Track Object dialog appears. 

a. Click New; select Event Log. The Event Log dialog appears. 

b. In the Name field, enter VirusLogl . 

c. From the scroll-list, select icap_virus_details, localtime, and client-address. Click 
Insert. 

d. Click OK; click OK again to add the object to the rule. 



RequestAV ResponseAV AVErrors 


No. Source Destination Service Time 


Action 


Track 


Comment 




1 |Any |Any Virus Detected |Any 


Q Deny 


|n VirusLogl 




□ 



Figure 11-9: The AVErrors rule 
Procedure — Create an Exception for IT Group 

1. In the VPM, select Policy>Add Web Access Layer. Name the rule AVExceptions. 

2. Add the IT group object to the Source column. 

3. Right-click the Service column; select Set. The Set Service Object dialog appears. 

a. Click New; select ICAP Error Code. The Add ICAP Error Code Object appears. 

b. Select Selected Errors 

c. From the list of errors, select Password Protected Archive; click Add. 
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d. Name the object password_protected. 

e. Click OK. 




Figure 11-10: Specifying an ICAP Error Code object 
f. Click OK; click OK again to add the object to the rule. 

4. Right-click the Action column and select Allow. 

5. Click Add Rule. 

6. In the Service column, add the password_protected object. 

7. Right-click the Action column; select Deny. 



RequestAV || ResponseAV || AVErrors | AVExceptions 



No. 


Source 


Destination 


Service 


Time 


Action 


Track 


Comment 


1 


fJJ cn=IT... 


Any 


^ password protected 


Any 


Q Allow 


None 




2 


Any 


Any 


password protected 


Any 


^ Deny 


None 





Figure 11-11: The AVException layer 
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Once this policy is installed: 

□ Virus scanning is performed for client attempts to upload content and content responses to client 
requests. 

□ If a virus is detected and there were no scanning process errors, a log entry occurs. 

□ As the ProxyAV is configured to serve password-protected objects, only the IT group can 
download such files; everyone else is denied. 

Exempting HTTP Live Streams From Response Modification 

The following CPL examples demonstrate how to exempt HTTP live streams from response 
modification, as they are not supported by ICAP. The CPL designates user agents that are bypassed. 

<cache> 

url . scheme=http request . header . User-Agent= "RealPlayer G2 " 
response . icap_service (no) 

url . scheme=http request . header . User-Agent= " ( RMA) " response . icap_service (no) 
url . scheme=http request . header . User-Agent= " (Winamp) " 
response . icap_service (no) 

url . scheme=http request . header . User-Agent= " (NSPlayer) " 
response . icap_service (no) 

url . scheme=http request . header . User-Agent= " (Windows-Media-Player) " 
response . icap_service (no) 

url . scheme=http request . header . User-Agent= "QuickTime " 
response . icap_service (no) 

url . scheme=http request . header . User-Agent= " (RealMedia Player) " 
response . icap_service (no) 

Streaming Media Request Modification Limitation 

Some HTTP progressive download streaming media transactions are complex enough to disrupt 
ICAP request modification services. If such behavior is noticed (most common with RealPlayer), 
implement the following workaround policy to bypass the ICAP request modification service for 
HTTP progressive downloads: 

<proxy> 

url . scheme=http request_header . User-Agent= " user_agent" 
request . icap_service (no) 

url . scheme=http request_header . User-Agent= " user_agent" 
request . icap_service (no) 

where user_agent specifies a media player attribute that is disrupting service. For example: 

<proxy> 

url . scheme=http request_header . User-Agent= " (RealMedia Player) " 
request . icap_service (no) 

url . scheme=http request_header . User - Agent = "RMA" request . icap_service (no) 
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CPL Notes 

□ If policy specifies that an ICAP service is to be used, but the service is not available, the default 
behavior is to fail closed — that is, deny the request or response. The following CPL allows the 
serving of objects without ICAP processing if the server is down. 

request. icap_service ( service_name , fail_open) 
response . icap_service ( service_name , f ail_open) 

When the ICAP service is restored, these objects are scanned and served from the cache if they are 
requested again. 



Note: Blue Coat recommends this CPL to be used for internal sites; use with caution. 



□ To provide an exception to a general rule, the following CPL negates ICAP processing: 

request . icap_service (no) 
response . icap_service (no) 

Managing Virus Scanning 

You might need to perform additional ProxySG maintenance concerning virus scanning, particularly 
for updates to the virus definition on the ICAP virus scanning server. 

Advanced Configurations 

This section summarizes more-advanced configurations between the ProxySG and multiple ICAP 
servers. These brief examples provide objectives and suggest ways of supporting the configuration. 

Using Object-Specific Scan Levels 

You can specify different scanning levels for different types of objects, or for objects from different 
sources. 

This requires a service group of ICAP servers, with each server configured to provide the same level 
of scanning. For more information, see "Creating a Service Group" on page 537. 

Improving Virus Scanning Performance 

You can overcome request-handling limitations of ICAP servers. Generally, ProxySGs can handle 
many times the volume of simultaneous user requests that ICAP servers can handle. 

This requires multiple ICAP servers to obtain a reasonable performance gain. On the ProxySG, define 
policy rules that partition requests among the servers. If you are going to direct requests to individual 
servers based on rules, configure in rule conditions that only use the URL. Note that you can increase 
the scale by using a service group, rather than use rules to partition requests among servers. For more 
information on using multiple ICAP servers, see "Creating a Service Group" on page 537. For more 
information on defining policies, see Chapter 13: "Managing Policy Files" on page 553, as well as the 
Blue Coat ProxySG Content Policy Language Guide. 
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When the virus definitions are updated, the ProxySG stores a signature. This signature consists of the 
server name plus a virus definition version. If either of these changes, the ProxySG checks to see if the 
object is up to date, and then rescans it. If two requests for the same object are directed to different 
servers, then the scanning signature changes and the object is rescanned. 

Updating the ICAP Server 

If there is a problem with the integration between the ProxySG and a supported ICAP server after a 
version update of the server, you might need to configure the preview size the appliance uses. For 
information, see "Creating an ICAP Service" on page 515. 

Replacing the ICAP Server 

If you replace an ICAP server with another supported ICAP server, reconfigure the ICAP service on 
the ProxySG: 

SGOS# (config) external - services 

SGOS# (config external-service) edit service_name 
SGOS# (config service_name ) url url 

For information about these commands, see "Creating an ICAP Service" on page 515. 

Access Logging 

The ProxySG provides access log support for Symantec and Finjan ICAP 1.0 server actions 
(Management>Access Logging). The following sections describe access logging behavior for the various 
supported ICAP servers. 

Symantec AntiVirus Scan Engine 4.0 

When this Symantec server performs a scan, identifies a problem (for example, a virus), and performs 
a content transformation, the action is logged. For example: 

"virus-id: Type=number; Resolution^ [0 | 1 | 2]; Threat =name;" 

where: 



TyP e=number 


Specifies the numeric code for the virus. 


Resolution= 


Specifies an integer value that indicates what action was taken to fix the 
file. Zero (o) defines the file is unrepairable, one (l) specifies that the file 
was repaired, and two ( 2 ) specifies that the file was deleted. 


Threat= 


Specifies the name of the virus. 
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Finjan SurfinGate 7.0 

When this Finjan ICAP server performs a scan, identifies a problem (for example, a virus), and 
performs a content transformation, the action is logged. For example: 

"virus-id: name, response- inf o : Blocked, response-desc : virus_name was 
detected" 

Finjan ICAP servers also log occurrences malicious mobile code. 



Note: The access log string cannot exceed 256 characters. If the header name or value extends 

the length over the limit, then that string does not get logged. For example, if the 
x-virus- id header value is 260 characters, the access log displays "x-virus-id: " with 
no value because the value is too long to display. Also, if the access log string is already 
250 characters and the ProxySG attempts to append a "Malicious-Mobile-Type : " 
string, the string is not appended. 



Access log entries might vary depending upon the type of ICAP scan performed and the custom log 
formats. For information about Access Logging, see Chapter 20: "Access Logging" on page 887. 



References 

The following are selected references for this feature. 



Note: As with any Web site, addresses are subject to change or deletion at any time. 



□ Symantec — A provider of Internet security technology, including content and network security 
software and appliance solutions. 

http : / /www . Symantec . com/ 

http : / /enterprise security . Symantec . com/products/ 

□ Finj an — A provider of proactive active content defense, virus protection, and Web and e-mail 
content filtering solutions. 

http : / /www . finj an . com/ 

□ ICAP Forum — A resource on Internet Content Adaptation Protocol (ICAP), an evolving Web 
architecture. ICAP effectively adapts content for user needs. 

http : / /www . i-cap . org/ 
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Section B: Websense 

This section describes how to create and manage Websense off-box services on the ProxySG. The 
ProxySG supports Websense off-box server versions 4.3 and higher. 

For more information about Websense and content filtering, see Chapter 18: "Content Filtering" on 
page 785. 

Creating a Websense Service 

To Configure a Websense Off-box Service through the Management Console 

1. Select Configuration>External Services>Websense. 

2. Click New; the Add List Item dialog appears. 

3. In the Add Websense Service field, enter an alphanumeric name; click OK. 

4. Highlight the new Websense service name and click Edit; the Edit Websense Service Name dialog 
appears. 




Figure 11-12: The Edit Websense Service Dialog 
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5. Enter following information: 

a. Select the Websense server version: 4.3 or 4.4 and higher. 

b. In the Host field, enter the hostname or IP address of the remote Websense server. 

c. In the Port field, enter the port number of the Websense server; or leave as is to accept the 
default (15868). 

d. In the Maximum connections field, enter the maximum number of connections. The range is 
a number from 1 to 65535. The default is 5. Blue Coat recommends that the setting not 
exceed 200. 

e. In the Receive Timeout field, enter the number of seconds the ProxySG waits for replies 
from the Websense server. The range is 60 to 65535. The default timeout is 70 seconds. 

6. Select the following options, as required: 

a. Fail open — If a default Websense service is selected (from the External Services>Websense 
tab), a connection error with the Websense server results in requests and responses 
proceeding, as the default Websense service is subjected to policy. 

b. Send client address — Sends the client IP address to the Websense server. 

c. Send Authenticated user — Sends user information to the Websense server. 

d. Serve exception page when content is blocked — If the requested content is defined by 
Websense as inappropriate, the client receives a page with information stating the content 
is blocked. When this option is selected, the exception page originates from the ProxySG; 
if not selected, the Websense server provides the exception page. 

7. Click OK. 

8. Optional: You can designate a default Websense service. On the Configuration>External 

Services>Websense tab, select a service from the Default service to use drop-down list. 

To Register a Newly Created Websense Service for Health Checking 

For convenience, the Edit Websense Service dialog allows you to register a newly-created Websense 

service for health checking (this duplicates the functionality on the Configuration>Health Checks>General 

tab). Registering for health checking requires that a valid Websense server URL was entered. 

□ Click Register; a dialog prompts confirmation; click OK. 

□ You can also click Health check to perform an immediate health check on this service. 

For more information about health checks, see Chapter 12: "Health Checks" on page 545. 

To Configure a Websense Service through the CLI 

1. At the (config) command prompt, enter the following commands: 

SGOS# (config) external - services 

SGOS# (config external-services) create websense service_name 
Specify a unique alphanumeric name for each service. 

2. To configure the service, enter the following commands: 

SGOS# (config external - services ) edit service_name 

SGOS# (config websense service_name ) version {4.3 | 4.4} 



535 



Blue Coat ProxySG Configuration and Management Guide 



Section B: Websense 

where version specifies 4.3 or 4.4 and higher. 

SGOS# (config websense service_name ) host {hostname \ IP_address } 

where hostname or ip_address specifies the Websense server. 

SGOS# (config websense service_name) port port_number 

where port_number specifies the port number of the Websense server. The default port 
number is 15868 . 

SGOS# (config websense service_name ) max-conn number 

where number is the maximum number, from 1 to 65535, of connections the Websense 
service uses to connect to the Websense server. The default number is 5 . Blue Coat 
recommends that the setting not exceed 2 0 0. 

SGOS# (config websense service_name ) timeout timeout_seconds 

where timeout_seconds is the number of seconds, from 60 to 65535, the ProxySG waits for 
replies from the Websense server. The default timeout is 7 0 seconds. 

SGOS# (config websense service_name ) send {client -address | 
authenticated -user} 

Specifies to send the client IP address or authenticated user information to the Websense 
server. 

3. Optional: You can automatically detect the categories defined on the Websense server. 

SGOS# (config websense service_name ) sense -categories 

4. Optional: You can designate a default Websense service. 

SGOS# (config websense service_name) apply-by-def ault 

This Websense service is now the default and is used if failover is enabled. 

5. Optional: You can enable failover. If a default Websense service is selected (from the External 
Services>Websense tab), a connection error with the Websense server results in requests and 
responses proceeding, as the default Websense service is subjected to policy. 

SGOS# (config websense service_name ) fail-open 

6. Optional: You can send a test URL to the Websense server to verify content filtering is active. 
SGOS# (config websense service_name) test-url url 

where url is a valid URL that points to a site determined categorized by Websense as 
inappropriate. 
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Deleting a Websense Service 

The following steps describe how to delete an Websense service. 



Note: You cannot delete a Websense service used in a ProxySG policy (that is, if a policy rule 

uses the Websense service name) or if the service belongs to a service group. 



To Delete a Websense Service through the Management Console 

1. Select Configuration>External Service>Websense. 

2. Select the service to be deleted. 

3. Click Delete; click OK to confirm. 

4. Click Apply. 

To Delete an Websense Service through the CLI 

At the (conf ig) prompt, enter the following commands: 

SGOS# (config) external - services 

SGOS# (config external - services ) delete service_name 

Section C: Service Groups 

This section describes how to create and manage ICAP or Websense service groups. In high-traffic 
network environments, a service group accelerates response time by a performing a higher volume of 
scanning. 

Creating a Service Group 

Create the service group and add the relevant ICAP or Websense services to the group. Services 
within group must be the same type (ICAP or Websense). 

To Configure a Service Group through the Management Console 

1. Select Configuration>External Services>Service-Groups. 

2. Click New; the Add List Item dialog appears. 

3. In the Add Service Group field, enter an alphanumeric name; click OK. 

4. Highlight the new service group name and click Edit; the Edit Service Group dialog appears. 
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Edit Service-Group test3 






- test3 Service-Group Entries: 




Figure 11-13: The Edit Service Group Dialog 

5. Click New to add a service to the service group; the Add Service Group Entry dialog appears. 



Add Service-Group Entry 



Available service-group entries: 



OK | [ Cancel ] 

Figure 11-14: The Add Service Group Entry Dialog 

6. Select List ICAP services or List Websense services. The picklist displays the available configured 
services that are eligible for this service group. 

7. Select a service; to select multiple services, use Ctrl-click. Click OK. 

8. To assign a weight value to a service, select a service and click Edit; the Edit Service Group Entry 
weight dialog appears. In the Entry Weight field, assign a weight value. The valid range is 0-255. 
For detailed information about service weighting, see the next topic, "About Weighted Load 
Balancing" on page 541. 

9. Click OK; click OK again to close the Edit Service Group Entry dialog. 



(•) List ICAP services 
O List Websense services 
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Note: If creating a Websense service group, neither the service group nor the Websense servers 

can be set to Apply-by-default. 



10. Click Apply. 

11. Create a policy that uses the service group to filter requests. 

• VPM: Create a Web Access Layer rule to send requests through the service group. 

• CPL: Create a proxy layer property: 

<proxy> 

request. f ilter_service ( group_name ) 

To Configure a Service Group through the CLI 

1. At the (conf ig) command prompt, enter the following commands: 

SGOS# (config) external - services 

SGOS# (config external - services ) create service-group name 
SGOS# (config service-group name) add service_name 

Enter a unique alphanumeric name for each service; the ICAP or Websense service must 
already exist on the ProxySG. 

2. Repeat the add service_name command for each service to be added. 

The type of service group (ICAP or Websense) is determined by the first service added. For 
example, if the first added service is an ICAP service, the service group is automatically 
defined as an ICAP service group. If you attempt to add a Websense service, an error is 
displayed. 

3. To assign weights to each service, enter the following commands: 

SGOS# (config service-group name) edit service_name 
SGOS# (config service-group name) weight value 

where value is from 0 to 255 . For information about weight values, see "About Weighted 
Load Balancing" on page 541. 



Note: If creating a Websense service group, neither the service group nor the Websense servers 

can be set to Apply-by-default. 



4. Create a policy that uses the service group to filter requests. 

• VPM: Create a Web Access Layer rule to send requests through the service group. 

• CPL: Create a proxy layer property: 

<proxy> 

request. f ilter_service ( group_name ) 
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Deleting a Service Group or Group Entry 

You can delete the configuration for an entire service group from the ProxySG, or you can delete 
individual entries from a service group. 



Note: A service or service group used in a ProxySG policy (that is, if a policy rule uses the entry) 

cannot be deleted; it must first be removed from the policy. 



To Delete a Service Group through the Management Console 

1. Select Configuration>External Services>Service-Groups. 

2. Select the service group to be deleted. 

3. Click Delete; click OK to confirm. 

4. Click Apply. 

To Delete a Service Group through the CLI 

At the (conf ig) command prompt, enter the following commands: 

SGOS# (config) external - services 

SGOS# (config external - services ) delete service_group_name 

To Delete a Service Group Entry through the Management Console 

1. Select Configuration>External Services>Service-Groups. 

2. Select the service group to be modified. 

3. Click Edit. 

4. Select the service entry; click Delete. 

5. Click OK; click Apply. 

To Delete a Service Group Configuration through the CLI 

At the (config) command prompt, enter the following commands: 

SGOS# (config) external - services 

SGOS# (config external - services ) edit service_group_name 
SGOS# (config type name) remove entry_name 
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About Weighted Load Balancing 

The ProxySG supports weighted load balancing in forwarding requests to service groups. By default, 
the ProxySG performs typical round-robin load balancing and evenly forwards requests sequentially 
to servers as defined within the service group. Manually assigning weights takes advantage of 
round-robin load balancing in service groups that are not homogeneous, or where the servers have 
different capacities. 

Weighting determines what proportion of the load one server bears relative to the others. If all servers 
have either the default weight (1) or the same weight, each share an equal proportion of the load. If 
one server has weight 25 and all other servers have weight 50, the 25-weight server processes half as 
much as any other server. 

Before configuring weights, consider the relative weights to assign to each server. Factors that could 
affect assigned weight of a ICAP server include the following: 

□ The processing capacity of the server hardware in relationship to other servers (for example, the 
number and performance of CPUs or the number of network interface cards) 

□ The maximum number of connections configured for the service. The maximum connections 
setting pertains to how many simultaneous scans can be performed on the server, while 
weighting applies to throughput in the integration. While these settings are not directly related, 
consider both when configuring weighted load balancing For more information on maximum 
connections, see "Creating an ICAP Service" on page 515 and "Creating a Websense Service" on 
page 534. 



Note: External services (ICAP, Websense off-box) have a reserved connection for health checks 

(if a health check service has been created). This means that, as the load goes up and the 
number of connections to the external service reaches the maximum, with additional 
requests being queued and waiting, the number of maximum simultaneous connections 
is actually one less than the limit. 



The table below provides an example of how weighting works with a service group of three ICAP 
servers, Serverl, Server2, and Server3. Because Server3 is a higher-capacity server (including dual 
CPUs and multiple network interface cards (NICs)) compared to Serverl and Server2, it is assigned a 
heavier weight. Using the weights below, for every 100 requests forwarded to the service group, 
Server3 receives 60 requests, while Serverl and Server2 each receive 20 requests. 

Table 1 1 .3: Example of Weighted Load Balancing for an ICAP Service Group 



ICAP server 


Capacity 


ICAP service / 
Maximum connections 


Weight 


Serverl 


Standard 


Servicel / 10 


1 


Server2 


Standard 


Service2 / 10 


1 


Server3 


High 


Service3 / 25 


3 
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Note: Setting the weight value to 0 (zero) disables weighted load balancing for the ICAP service. 

Therefore, if one ICAP server of a two-server group has a weight value of 1 and the 
second a weight value of 0, should the first server go down, a communication error 
results because the second server cannot process the request. 



While you cannot specifically designate an ICAP server in a group as a backup, you can specify 
weight values that create a large differential between a server that is used continuously and one that is 
rarely used, thus simulating a backup server. 



Section D: Displaying External Service and Group Information 



After configuring a service or service group, you can display information either for all or individual 
service groups. 



To Display Information about all External Services and Groups through the CLI 

At the (conf ig) command prompt, enter the following commands: 

SGOS# (config) external - services 

SGOS# (config external-services) view 



Individual service information is displayed first, followed by service group information. For example: 



; External Services 
icap4 

ICAP-Version : 1.0 



URL: 

Max- conn : 

Timeout (secs) : 
Health-checks : 
Patience-page (secs) 
Notification : 
Methods : 
Preview-size : 



icap : //10 . 1 . 1 . 1 
5 

70 



no 

disabled 

never 

RESPMOD 

0 



Send: nothing 

ISTag: 



websense4 
Version : 
Host : 



4.4 

www . websense . com/list 



Port: 15868 

Max -conn: 5 

Timeout (secs) : 70 

Send: nothing 

Fail -by-default : closed 

Apply-by-def ault : no 



Serve-exception-page :yes 
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; External Service -Groups 
CorpICAP 

total weight 5 
entries : 

ICAP1 
weight 4 
ICAP2 
weight 1 
BranchWebsense 
total weight 2 
entries : 

Websensel 
weight 1 

Websense2 
weight 1 

To Display Information about an Individual Service or Service Group through the CLI 

At the (conf ig) command prompt, enter the following commands: 

SGOS (config) external - services 

SGOS# (config external - services ) edit {service_name \ service_group_name } 
SGOS# (config type name) view 
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This chapter discusses health checks for services and hosts and describes how to configure the 
ProxySG. 



About General Health Checks 

The ProxySG can perform health checks on a forwarding host or external server that is providing a 
service. The supported server types are HTTP, HTTPS, ICAP, Websense (off-box), and SOCKS 
gateways, Layer-3, and Layer 4 forwarding hosts. 

Based on the health check type, the ProxySG periodically verifies the health status, and thus the 
availability, of the host. The time interval between checks is configurable. If the health check is 
successful, the ProxySG considers the host available. If the initial health check is not successful for a 
host, the ProxySG retries, using the number of attempts in the health check failure count. If the health 
check is not successful for every server in a domain, the ProxySG might not serve stale content from its 
object store, depending on the ProxySG configuration. 

The following table describes the types of health checks. 



Table 12.1 : Types of Health Checks 



Health Check Type 


Description 


HTTP 


Use this type to confirm that the host can fulfill a content 
request over HTTP by the ProxySG. The ProxySG accepts 
only a 200 OK as a healthy response. 


Criterion for success 


The ProxySG fetches the object. 


Criterion for failure 


The ProxySG cannot fetch the object. 


HTTPS 


Use this type to confirm that the host can fulfill a content 
request over HTTPS by the ProxySG. The ProxySG accepts 
only a 200 OK as a healthy response. 


Criterion for success 


The ProxySG fetches the object. 


Criterion for failure 


The ProxySG cannot fetch the object. 


Layer-3 health check 


Use this type to confirm the basic connection between the 
ProxySG and the origin server. The server must recognize 
ICMP echoing. The ProxySG sends a ping (three Internet 
Control Message Protocol [ICMP] echo requests) to the host. 


Criterion for success 


The ProxySG receives at least one ICMP echo reply. 


Criterion for failure 


The ProxySG does not receive a single ICMP echo reply. 
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Health Check Type 


Description 


Layer-4 health check 


Use this type to confirm that the ProxySG can connect to the 
host HTTP and FTP ports. The ProxySG attempts to establish 
a TCP connection to an HTTP port or FTP port on the host. 


Criterion for success 


The ProxySG establishes the connection to the defined port 
(of any type), then closes it. For global forwarding checks, the 
first defined port in the forwarding host port list is used for 
the attempt (except for SOCKS gateways, in which the 
SOCKS port is used). 


Criterion for failure 


The ProxySG cannot establish the connection. 


ICAP health check and Websense 4 off-box 


Requests are not sent to sick services. If a health check 
determines the service is healthy, requests resume. 



Configuring Service-Specific Health Checks 

This section describes how to create a health check service for a specific host (for example, an ICAP 
server). A failed health check results in administrator notification; however, unlike global forwarding 
health checks, the Proxy SG does not recognize the healthy or sick status of the host and thus alters 
where it sends transactions. 

To Configure Health Checks through the Management Console 
Part 1: General Tasks 

This part of the procedures is the same for all health check types. 

1. Select Configuration>Health Checks>General. 

2. Click New. 

3. In the Add Health Check dialog, specify a name for the health check service; click OK. 

4. In the Health Check list, select the newly created service and click Edit; the Edit Health Check dialog 
displays. 
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n 


Edit Health Check HC1 


^njxj 





Health Check Settings 



Type of health check: 
Healthy interval (seconds): 
Sick interval (seconds): 
Failure trigger ( 0 to disable ): 
Healthy threshold: 

Sick threshold: 

V Notify via e-mail 
I CAP Options 



I CAP 



10 



10 



I CAP service: | no service selected 






~n 



Health Check | Perform a health check now 

Statistics View statistics for HC1 



OK | Cancel | 

Figure 12-1: Edit Health Check Dialog 

5. Select the health check type (HTTP, HTTPS, ICAP, Layer-3, Layer-4, or Websense off-box). 

6. Specify the healthy interval, in seconds, between health checks to the server. The default is 1 0. 

7. Specify the sick interval, in seconds, between health checks to the server that has been determined 
to be sick, or out of service. The default is 1 0. 

8. Specify the failure trigger, or the number of failed connections to the server before a health check is 
triggered. Valid values are 0-65535, where 0 disables the trigger. The default is 0. 

9. Specify the healthy threshold, or the number of successful health checks before an entry is 
considered healthy. Valid values are 1-65535. The default is 1. 

10. Specify the sick threshold, or the number of failed health checks before an entry is considered sick. 
Valid values are 1-65535. The default is 1 . 

11. Optional: Select the Notify via email checkbox to send notification mail when the health of a service 
changes. Recipients are specified in Management>Event Logging>Mail. 
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This part of the procedure configures the health check based upon the type selected. 

1. Upon selecting the health check type, the Options section of the dialog changes to display the 
appropriate configuration fields. Enter the required information: 

• HTTP and HTTPS: Enter the URL of the server to be checked. 

• ICAP: Select the ICAP service. The ICAP service must already be configured on the ProxySG 
(see Chapter 11: "External Services" on page 511). 

• Layer-3 and Layer-4: Enter the host name; for Layer-4, also enter the port number. 

• Websense off-box: Select the Websense service. The Websense service must already be 
configured on the ProxySG (see Chapter 11: "External Services" on page 511). Enter the URL 
to be test-categorized, or click Use default. 

2. Click OK to close the Edit Health Check dialog; Click Apply to apply the configuration to the 
ProxySG. 

To Specify a Health Check through the CLI 

At the (config) command prompt, enter the following commands: 

SGOS# (config) health-check 

SGOS# (config health-check) create name 

SGOS# (config health-check) edit name 

SGOS# (config health-check name) type {layer-3 | layer-4 | http | https | icap 
| websense-of fbox} 

where type specifies the type of health check. 

SGOS# (config health-check name ) type parameter 

where type is the type of health check and parameter is the required attribute: 

layer-3 hostname hostname 
layer-4 hostname hostname 
layer- 4 port port 
{http | https} url url 

icap servicename service_name — The ICAP service must already be configured on the 
ProxySG. See Appendix 11: "External Services". 

websense-of fbox servicename service_name — The Websense service must already be 
configured on the ProxySG. For more information, see Chapter 11: "External Services" on page 
511. 

websense-of fbox {url | default-url} 

SGOS# (config health-check name) interval healthy seconds 

where seconds specifies the interval between health checks to the server. The default is 10. 
SGOS# (config health-check name) interval sick seconds 

where seconds specifies the interval between health checks to the server that has been 
determined to be sick. The default is 10. 

SGOS# (config health-check name) threshold healthy number 
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where number is the number of successful health checks before an entry is considered healthy. 
Valid values are 1-65535. The default is 1. 

SGOS# (config health-check name) threshold sick number 

where number is the number of failed health checks before an entry is considered sick. Valid 
values are 1-65535. The default is l. 

SGOS# (config health-check name) failure-trigger number 

where number is the number of failed connections to the server before a health check is 
triggered. Valid values are 0-6553 5, where o disables the trigger. The default is o. 

Optional: 

SGOS# (config) health-check name) notify 

Sends e-mail notification when the health of a service changes. The recipients are specified in 
(config event-log) mail add option. 

Perform an Instant Health Check 

You can manually issue a health check request. 

To Invoke a Health Check through The Management Console 

1. Select Health Checks>General. 

2. Select a health check name. 

3. Click Edit. 

4. Click Health Check. 

To Invoke a Health Check through the CLI 

At the (config) prompt, enter the following commands: 

SGOS# (config) health-check 

SGOS# (config) health-check) edit health_check_name 
SGOS# (config) health-check name) perform-health-check 

Viewing Health Check Statistics 

You can display a page that displays all user-created health check statistics, organized by health check 
service. 

To Display Health Check Statistics: 

1. Select Configuration>Health Checks>General. 

2. Click Statistics. The Health Check Statistics page appears. For example: 

ICAPl 

State: Functioning properly 

Last success: Wed, 23 Nov 2005 20:56:15 GMT 
Number of successes: 86 
Consec. successes: 86 
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Last failure: Wed, 23 Nov 2005 20:41:14 GMT 

Number of failures: 1 

Consec. failures: 0 

External failures : 0 

Response time: 586 ms 

About Global Forwarding and SOCKS Gateway Health Checks 

This section describes health checks that can be configured on the ProxySG that apply to all 
forwarding hosts and SOCKS gateway hosts. 

When the ProxySG performs a health check on one or more hosts, it determines whether the host 
returns a response and is available to fill a content request. A positive health check indicates that there 
is an end-to-end connection and that the host is healthy and is able to return a response. 

With multiple forwarding hosts, health checks are vital to ProxySG efficiency. When hosts respond 
positively to health checks, the ProxySG forwards requests to those hosts and not to unavailable hosts, 
which provides quicker content fill requests. With a single forwarding host, health checking is also 
important determine whether the host is available. 



Note: When a forwarding host or SOCKS gateway is created, it is automatically registered for 

health checks. Similarly, when a forwarding host or SOCKS gateway is deleted, it is 
removed from the health check registry. 



Configuring Global Health Checks 

This section describes how to configure the ProxySG to perform global health checks. 

To Configure Global Forwarding or Socks Gateway Health Checks through the Management Console 
1. Select Configuration>Health Checks>Forwarding or SOCKS Gateway. 

Forwarding Health Checks 




Figure 12-2: The Forwarding Health Check tab 
2. Select the health check type: 

• Forwarding — HTTP, HTTPS, Layer-3, or Layer-4. 

• SOCKS Gateway — Layer-3 or Layer-4. 
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3. (HTTP/ HTTPS only) Object name — Enter a relative URL (path) to test a server or enter a full URL, 
(including scheme and hostname) to test a proxy. A full URL scheme must match the HTTP or 
HTTPS test to be accepted. If the test is performed on a mix of servers and proxies, the health 
check attempts to make up a full URL out of the path and make a path out of the full URL, as 
required. For a proxy, enter the full URL of the upstream target. 

4. Specify the interval, in seconds, between health checks. The default is 60. 

5. Specify the failure count, which specifies the number of sequential failures before the host is 
considered down. The default is 5. 

6. Click Apply. 

To Configure Global Forwarding Host Health Checks through the CLI 

At the (conf ig) command prompt, enter the following commands: 

SGOS# (config) health-check 

SGOS# (config health-check) forwarding type {http | https | layer-3 | layer-4} 

SGOS# (config health-check) forwarding interval seconds 

where seconds specifies the time between health checks. 

SGOS# (config health-check) forwarding failcount count 

where count specifies the number of sequential failures before the host is considered down. 
The default is 5. 

To Configure Global SOCKS Gateways Health Checks through the CLI 

At the (config) command prompt, enter the following commands: 

SGOS# (config) health-check 

SGOS# (config health-check) socks -gateways type {layer-3 | layer-4} 

SGOS# (config health-check) socks -gateways interval seconds 

where seconds specifies the time between health checks. 

SGOS# (config) health-check) socks-gateways failcount count 

where count specifies the number of sequential failures before the host is considered down. 
The default is 5. 

Pausing or Resuming Global Health Checking 

You can temporarily halt global health checks and resume when ready. This is helpful if the ProxySG 
needs to be temporarily taken out of service. 



Note: If the health check is paused, the state remains paused until the resume option is invoked. 

The paused state remains even after a reboot. 



To Pause or Resume Health Checking through the Management Console 

1. Select Configuration>Health Checks>Forwarding or SOCKS Gateway. 

2. Click Pause. 

To resume health checks, click Resume. 



3. 
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To Pause or Resume Health Checking through the CLI 

At the (config) command prompt, enter the following commands: 

SGOS# (config) ) health-check 

SGOS# (config) health-check) {forwarding [ socks -gateway } {pause | resume} 
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Policy files contain the policies that manage every aspect of the ProxySG, from controlling user 

authentication and privileges to disabling access logging or determining the version of SOCKS. 

The policy for a given system can contain several files with many layers and rules in each. Policies can 

be defined through the Visual Policy Manager (VPM) or composed in Content Policy Language (CPL). 

(Some advanced policy features are not available in VPM and can only be configured through CPL.) 

Policies are managed through four files: 

□ Central policy file — Contains global settings to improve performance and behavior and filters for 
important and emerging viruses (such as Code Red and Nimda). This file is usually managed by 
Blue Coat, although you can point the ProxySG to a custom Central policy file instead. 

□ Forward policy file — Usually used to supplement any policy created in the other three policy files. 
The Forward policy file contains Forwarding rules when the system is upgraded from a previous 
version of SGOS (2.x) or CacheOS (4.x). 

n Local policy file — A file you create yourself. When the VPM is not the primary tool used to define 
policy, the Local file contains the majority of the policy rules for a system. If the VPM is the 
primary tool, this file is either empty or includes rules for advanced policy features that are not 
available in VPM. 

□ Visual Policy Manager — The policy created by the VPM can either supplement or override the 
policies created in the other policy files. 

This chapter contains the following sections: 

□ "About Policy Files" 

n "Creating and Editing Policy Files" 

□ "Managing the Central Policy File" 

□ "Viewing Policy Files" 

To learn about writing policies, refer to the Blue Coat ProxySG Content Policy Language Guide. 

About Policy Files 

When creating the files, keep in mind: 

D The order in which the files are evaluated. 

□ The transaction default settings, which control whether you allow everything or deny everything 
by default. 

n Whether to use the VPM. 
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Policy File Evaluation 

The order in which the ProxySG evaluates policy rules is important. Changes to the evaluation order 
can result in different effective policy, as the order of policy evaluation defines general rules and 
exceptions. While this order is configurable, the default and recommended order is: 

VPM File— Local Policy File— Central Policy File-Forward File 

This prevents policies in the Central file that block virus signatures from being inadvertently 
overridden by allow (access-granting) policy rules in the VPM and Local files. 

When changing the policy file evaluation order, remember that final decisions can differ because 
decisions from files later in the order can override decisions from earlier files (the Forward policy file 
order cannot be changed). 

For a new ProxySG, the default evaluation order is: VPM, Local, Central, and Forward. 

For an upgraded ProxySG, the policy evaluation order is the order already existing on the appliance 
before the upgrade. 

To Change Policy Order through the Management Console 
1. Select Configuration>Policy>Policy Options. 



Policy Options 

r Policy Evaluation Order 




- Default Proxy Policy 




- Default Policy Tracing 


O Allow 




| | T race all policy execution 




Only enable this feature when trouble-shooting 


® Deny 




specific policy issues. Do not leave this 
feature turned on as a permanent setting 



Figure 13-1: Policy Options Tab 

2. To change the order, select the file to move and click Move Up or Move Down. Remember that the 
last file in the list overwrites decisions in files evaluated earlier. 

To Change Policy Order through the CLI 

At the (config) command prompt, enter the command: 

SGOS# (config) policy order vie 

where v (VPM), 1 (local), and c (central) specify the order of evaluation. These are 
case-insensitive, but you must enter all three in any order, including a space between each 
letter. 



Note: Use the show policy order command to check the current settings. 
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Transaction Settings: Deny and Allow 

The default proxy transaction policy is to either deny proxy transactions or to allow proxy transactions. A 
default proxy transaction policy of Deny prohibits proxy-type access to the ProxySG: you must then 
create policies to explicitly grant access on a case-by-case basis. 



Note: the default proxy policy does not apply to admin transactions. By default, admin 

transactions will always be denied unless you log in using console account credentials or 
if explicit policy is written to grant read-only or read-write privileges. 



The default depends on how you installed the SGOS and if it was a new installation or an upgrade: 

□ If you installed the SGOS through a browser using the Initial Configuration Web site, you chose 
whether to allow or deny proxied transactions during initial configuration. 

□ If you installed the SGOS using the front panel or a serial console port, the default setting is Deny. 

□ If you upgraded the SGOS from a previous version, the default remains whatever it was for the 
previous policy. 

You can always change the setting — see the procedures below for instructions. 

Also keep in mind that: 

□ Changing the default proxy transaction policy affects the basic environment in which the overall 
policy is evaluated. It is likely that you must revise policies to retain expected behavior after such 
a change. 

□ Changes to the evaluation order might result in different effective policy, because the order of 
policy evaluation defines general rules and exceptions. 

□ Changing the default proxy transaction policy does not affect the evaluation of cache and admin 
transactions. 

To Configure Deny or Allow Default Proxy Policy through the Management Console 

1. Select Configuration>Policy>Policy Options. 

2. Under Default Proxy Policy, select either Deny or Allow. 

3. Click Apply. 

To Configure the Deny or Allow Proxy Transaction Policy through the CLI 

At the (config) command prompt, enter the following command 
SGOS# (config) policy proxy-default {allow | deny} 



555 



Blue Coat Proxy SG Configuration and Management Guide 



Policy Tracing 

Tracing enabled with the Management Console or CLI is global; that is, it records every policy-related 
event in every layer. It should be used only while troubleshooting. For information on 
troubleshooting policy, refer to the Blue Coat ProxySG Content Policy Language Guide. Turning on policy 
tracing of any kind is expensive in terms of system resource usage, and slows down the ProxySG's 
ability to handle traffic. 

To Enable Policy Tracing through the Management Console 

1. Select Configuration>Policy>Policy Options. 

2. Select Trace all policy execution. 

3. Click Apply. 

To Enable Policy Tracing through the CLI 

From the command prompt, enter the following command: 

SGOS# policy trace {all | none} 

Creating and Editing Policy Files 

You can create and edit policy files two ways: 

□ Through the Management console (recommended). 

□ Through the CLI inline policy command (not recommended because the policies can grow large 
and using inline policy overwrites any existing policy on the ProxySG). 

You can use VPM to create policy layers and rules in the VPM file. For information on managing the 
VPM file, see Chapter 14: "The Visual Policy Manager" on page 567. 

To create or edit policy files, use CPL to define policy rules (refer to the Blue Coat ProxySG Content 
Policy Language Guide). You can use the Management Console or CLI to create or edit policy files 
directly, or create a file that can be uploaded to the ProxySG through the Management Console or CLI. 

Create and Edit Policy Files 

You can install the policy files in the following ways. 

□ Using the ProxySG Text Editor, which allows you to enter directives (or copy and paste the 
contents of an already-created file) directly onto the ProxySG. 

□ Creating a local file on your local system; the ProxySG can browse to the file and install it. 

□ Using a remote URL, where you place an already-created file on an FTP or FITTP server to be 
downloaded to the ProxySG. 

□ Through the CLI inline command. 

The ProxySG compiles the new policy from all source files and installs the policy, if the compilation is 
successful. 
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Important: If errors or warnings are produced when you load the policy file, a summary of the 
errors and/or warnings is displayed automatically If errors are present, the policy 
file is not installed. If warnings are present, the policy file is installed, but the 
warnings should be examined. 



To Define and Install Policy Files Directly through the Management Console 
1. Select Configuration>Policy>Policy Files>Policy Files. 

Policy Files j Visual Policy Files 

r Install Policy 



Install Local File from: 


Remote URL v 


Install 






Install Forward File from: 


Remote URL v 


Install 






Install Central File from: 


Remote URL v 


Install 



| | Automatically install new Policy when central file changes 
| | Send me email when central file changes 



- View Policy - 

View File: 



Figure 13-2: Policy Files Tab 

2. From the appropriate Install Local/Forward/Central File from drop-down list, select the method used to 
install the local, forward, or central policy configuration; click Install and complete one of the three 
procedures below: 



Note: A message is written to the event log when you install a list through the ProxySG. 



Current Policy 



View 



• Installing a policy file using a Remote URL: 

In the Install Local /Forward /Central File dialog that appears, enter the fully-qualified URL, 
including the filename, where the policy configuration is located. To view the file before 
installing it, click View. Click Install. The Installation Status field summarizes the results; click 
Results to open the policy installation results window. Close the window when you are 
finished viewing the results; click OK in the Install Local/Forward/Central File dialog. 
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• Install Central File 



-jDjxl 




OK | Cancel | ^ResultsJ 

Figure 13-3: Policy Files Remote Installation Dialog 



Note: If you use the default Blue Coat Central policy file, load it from: 

https : // download . bluecoat . com/ release/ SG3 / files /CentralPol icy . txt 

If you install a Central policy file, the default is already entered; change this field only 
if you want to create a custom Central policy file. 

To load a Forward, Local, or a custom Central policy file, move it to an HTTP or FTP 
server, and then use that URL to download the file to the ProxySG. 



• Installing a policy file using a Local File: 

In the Upload and Install File window that opens, either enter the path to the file into the File 
to upload field, or click Browse to display the Choose file dialog, locate the file on the local 
system, and open it. Click Install. When the installation is complete, the installation results 
display. View the results and close the window. 



Upload and Install File home i support i documentation i log out 

Systems | 



Upload and Install the Central Policy File 

1 . Paste the file path into the box below or choose a file 
by clicking the Browse... button and opening the file. 

2. Click Install to upload and install the new file. It can 
take some time for the upload to complete. Your 
browser may be unresponsive during the upload. 

3. Once the installation is completed the results will be 
displayed in a new page. Close the results page once 
you have finished viewing the results. 

File to upload: 

Browse- 

Install | Close | 



Coat Systems 



, Inc. All rights reserved. 



Copyright ©2002-2003. Blu 




Figure 13-4: Specifying the Local Location of a Policy File 
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• Installing a policy file using a Text Editor: 

The current configuration is displayed in installable list format. Define the policy rules using 
CPL in the Edit and Install File window that opens (refer to the Blue Coat ProxySG Content 
Policy Language Guide); click Install. When the installation is complete, a results window opens. 
View the results, close the results window and click Close in the Edit and Install File window. 




Figure 13-5: Edit and Install File Window 

Using the CLI Inline Command 

To create policies using the CLI, you can use the ProxySG inline policy command. This command 
either creates a new policy file or, if the specified file already exists, overwrites an existing policy file. 
You cannot edit an existing policy file using this command. 



Note: If you are not sure whether a policy file is already defined, check before using the inline 

policy command. For more information, see "Viewing Policy Source Files" on page 564. 



To Create Policy Files through the CLI 

1. At the (config) command prompt, enter the following command: 

SGOS# (config) inline policy file end-of -input-marker 

where file specifies the type of policy you want to define: Central (Central policy file). 
Forward (Forward policy file), or local (local policy file). 

Note: Do not use the inline policy command with files created using the VPM module. 
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end-of- file-marker — Specifies the string that marks the end of the current inline 
command input; eof usually works as a string. The CLI buffers all input until you enter the 
marker string. 

2. Define the policy rules using CPL (refer to the Blue Coat ProxySG Content Policy Language Guide). 

3. Enter each line and press <Enter>. To correct mistakes on the current line, use <Backspace>. If a 
mistake has been made in a line that has already been terminated by <Enter>, exit the inline 
policy command by typing <Ctrl>c to prevent the file from being saved. 

4. Enter the eof marker to save the policies and exit the inline mode. 

For more information on the inline command, refer to the Blue Coat ProxySG Command Line Reference. 

To Load Policy Files through the CLI 

At the (config) command prompt, enter the following commands: 

SGOS# (config) policy {forward-path | local-path | central-path} url 
SGOS# (config) load policy {forward | local | central} 

The ProxySG compiles and installs the new policy. The ProxySG might display a warning if the new 
policy causes conflicts. If a syntax error is found, the appliance displays an error message. For 
information about these messages, refer to the Blue Coat ProxySG Content Policy Language Guide. 
Correct the error, then reload the file. 

Unloading Policy Files 

To disable policies, do the following procedure to unload the compiled policy file from the ProxySG 
memory. These steps describe how to replace a current policy file with an empty policy file. 

To keep a current policy file, either make a backup copy or rename the file before unloading it. By 
renaming the file, you can later reload the original policy file. If you use multiple policy files, back up 
or rename files as necessary. Alternatively, rather than use an empty policy file, you can delete the 
entire contents of the file, then reload it. 

To unload policies defined using the VPM, you can either: 

□ Do the procedure below for unloading policies through the CLI. 

□ Use the VPM and individually delete all layers. 

To Unload Policies through the Management Console 

1. Select Configuration>Policy>Policy Files>Policy Files. 

2. Select Text Editor in the Install Local/Forward/Central File from drop-down list and click the appropriate 
Install button. 

The Edit and Install the Local/Forward/Central Policy File window opens. 

3. Delete the text and click Install. 

4. View the results in the results page that opens; close the page. 

5. Click Close. 



560 



Chapter 13: Managing Policy Files 



To Unload Policies through the CLI 

1. At the (config) command prompt, enter the following command: 
SGOS# (config) inline policy file end-of -input-marker 



where: 



file 


Specifies the type of policy you want to define: central (central policy 
file), local (local policy file), vpm-cpl, or vpm-xml (VPM policy files, 
usually defined using the VPM). 


end-of - input -marker 


Specifies the string that marks the end of the current inline command 
input. The CLI buffers all input until you enter the marker string, eof is 
commonly used as the marker. 



Note: If you use the CLI to unload VPM-generated policies, you must run the inline command 

twice; once for the CPL file and once for the XML file. 



2. Enter an end-of -input -marker to save the policies and exit inline mode. Enter nothing else. 

3. If you use multiple policy files, repeat step 1 and step 2 for each policy file used. 

For more information on the inline policy command, refer to the Blue Coat ProxySG Command Line 
Reference. 

Managing the Central Policy File 

The Central policy file is updated when needed by Blue Coat. The file can be updated automatically or 
you can request e-mail notification. You can also configure the path to point to your own custom 
Central policy file. 

Configuring Automatic Installation 

You can specify whether the ProxySG checks for a new version of the Central policy file. If a new 
version exists, the appliance can install it automatically. 

Configuring the ProxySG for Automatic Installation 

Do the following procedure to configure the ProxySG to check for and install a new version of the 
Central policy file. 

To Configure Automatic Installation through the Management Console 

1. Select Configuration>Policy>Policy Files>Policy Files. 

2. Select Automatically install new Policy when central file changes. 

3. Click Apply. 

To Configure Automatic Installation through the CLI 

At the (config) command prompt, enter the following command: 
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SGOS# (config) policy subscribe 

Configuring a Custom Central Policy File for Automatic Installation 

If you define your own Central policy file, you can configure the ProxySG to automatically install any 
subsequent updated version of the file. To use this capability, you must change the Central policy file's 
first line with each version update. With automatic installation, the ProxySG checks for a change to the 
first line of the file. In defining a custom Central policy file, add an item, such as a comment, to the 
first line of the Central policy file that changes with each update. The following is a sample first line, 
containing date information that is routinely updated with each version: 

; Central policy file MonthDate, Year version 

When you update and save the file in the original location, the ProxySG automatically loads the 
updated version. 

Configuring E-mail Notification 

You can specify whether the ProxySG sends e-mail when the Central policy file changes. The e-mail 
address used is the same as that used in diagnostic reporting: the event recipient for the custom 
heartbeat e-mail. For information about diagnostic reporting, see "Diagnostic Reporting (Heartbeats)" 
on page 1137. 

To Configure E-mail Notification through the Management Console 

1. Select Configuration>Policy>Policy Files>Policy Files. 

2. Select Send me email when central file changes. 

3. Click Apply. 

To Configure E-mail Notification through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) policy notify 

Configuring the Update Interval 

You can specify how frequently the ProxySG checks for a new version of the Central policy file. By 
default, the appliance checks for an updated Central policy file once every 24 hours (1440 minutes). 
You must use the CLI to configure the update interval. You cannot configure the update interval 
through the Management Console. 

To Configure the Update Interval through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) policy poll-interval minutes 



562 



Chapter 13: Managing Policy Files 



Checking for an Updated Central Policy File 

You can manually check whether the Central policy file has changed. You must use the CLI. You 
cannot check for updates through the Management Console. 

To Check for an Updated Central File through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) policy poll-now 

The ProxySG displays a message indicating whether the Central file has changed. 

Resetting the Policy Files 

You can clear all the policy files automatically through the CLI. 

To Clear all Policy Files through the CLI 

1. At the (config) command prompt, enter the following command: 

SGOS# (config) policy reset 

WARNING: This will clear local, central, forward and VPM policy. Are you sure 
you want to reset ALL policy files? (y or n) 

The ProxySG displays a warning that you are resetting all of your policy files. 

2. Enter y to continue or n to cancel. 



Note: This command does not change the default proxy policy settings. 



Moving VPM Policy Files from One ProxySG to Another 

VPM policy files are specific to the ProxySG where they were created. But just as you can use the same 
Central, Local, and Forward policy files on multiple ProxySG Appliances, you can use VPM policies 
created on one appliance on other appliances. 

For detailed information on moving VPM policy files, see "Installing VPM-Created Policy Files" on 
page 678 in Chapter 14: "The Visual Policy Manager" on page 567. 

Viewing Policy Files 

You can view either the compiled policy or the source policy files. Use these procedures to view 
policies defined in a single policy file (for example, using VPM) or in multiple policy files (for 
example, using the Blue Coat Central policy file and VPM). 

Viewing the Installed Policy 

Use the Management Console or a browser to display installed Central, Local, or Forward policy files. 



Note: You can view VPM policy files through the Visual Policy Files tab. 
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To View Installed Policy through the Management Console 

1. Select Configuration>Policy>Policy Files>Policy Files. 

2. In the View File drop-down list, select Current Policy to view the installed and running policy, as 
assembled from all policy source files. You can also select Results of Policy Load to view any 
warnings or errors resulting from the last attempt (successful or not) to install policy. 

3. Click View. 

The ProxySG opens a separate browser window and displays the installed policy file. 

To View the Currently Installed Policy through a Browser: 

1. Enter a URL in one of the following formats: 

• If an HTTPS-Console is configured, use 

https : / / ip_address_of_ProxySG : HTTPS - Console_port / Policy / current (the default 
port is 8082). 

• If an HTTP-Console is configured, use 

http : / / ip_address_of_ProxySG : HTTP-Console_por t/Policy/current (the default port 
is 8081). 

The ProxySG opens a separate browser window and displays the policy. 

2. Review the policy, then close the browser. 

To View the Currently Installed Policy through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) show policy 

Viewing Policy Source Files 

You can display source (uncompiled) policy files on the ProxySG. 

To View Policy Source Files through the Management Console 

1. Select Configuration>Policy>Policy Files>Policy Files. 

2. To view a policy source file, select the file you want to view (Local, Forward, or Central) from the 
View File drop-down list and click View. 

The ProxySG opens a separate browser window and displays the appropriate source policy file. 

To View Policy Source Files through the CLI 

At the (config) command prompt, enter one of the following commands: 

SGOS# (config) show configuration 

-or- 

SGOS# (config) show sources policy {central | local | forward | vpm-cpl | 
vpm-xml } 
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The show configuration command displays general configuration information, followed by the 
policy source file contents. If the ProxySG is using multiple policy files, file source displays in this 
sequence: Central file, local file, VPM. The show sources policy command allows you to specify the 
policy files you want to view. 



Note: You can use the show configuration command to save the output to a file for reference, 

in addition to displaying the current configuration. For more information, refer to the Blue 
Coat ProxySG Command Line Reference. 



Viewing Policy Statistics 

You can view policy statistics on all requests processed by the ProxySG. Use the Management Console 
or a browser. You cannot view policy statistics through the CLI. 

To Review Policy Statistics through the Management Console 

1. Select Statistics>Advanced. 

2. Click the Policy link. 

3. Click the Show policy statistics link. 

A separate browser window opens and displays the statistics. 

4. Examine the statistics, then close the browser. 

To Review Policy Statistics through a Browser 

1. Enter a URL in one of the following formats: 

• If an HTTPS-Console is configured, use 

https : / / ip_address_of_ProxySG : HTTPS -Consol e_port/ Pol icy/ statistics (the default 
port is 8082). 

• If an HTTP-Console is configured, use 

http : / / ip_address_of_PvoxySG : HTTP-Console_port/Policy/statistics (the default 
port is 8081). 

The ProxySG opens a separate browser window and displays the statistics. 

2. Examine the statistics, then close the browser. 



565 



Blue Coat Proxy SG Configuration and Management Guide 



566 



Chapter 14: The Visual Policy Manager 



The Visual Policy Manager (VPM) is a graphical policy editor included with the ProxySG. The VPM 
allows you to define Web access and resource control policies without having an in-depth knowledge 
of Blue Coat Content Policy Language (CPL) and without the need to manually edit policy files. 

This chapter serves as a VPM object reference, and assumes that you are familiar with basic concepts 
of ProxySG policy functionality as described in Appendix 13: "Managing Policy Files". 

While VPM creates only a subset of everything you can achieve by writing policies directly in CPL, it 
is sufficient for most purposes. If your needs require more advanced policies, consult the Blue Coat 
ProxySG Content Policy Language Guide. 

This chapter contains the following sections: 

□ "Section A: About the Visual Policy Manager" 

n "Section B: Policy Layer and Rule Object Reference" 

□ "Section C: Detailed Object Column Reference" 

□ "Section D: Managing Policy Layers, Rules, and Files" 

□ "Section E: Tutorials" 

Related topics: 

□ Blue Coat ProxySG Content Policy Language Guide 

□ Appendix 13: "Managing Policy Files" 

□ Appendix 18: "Content Filtering” 
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Section A: About the Visual Policy Manager 

Section A: About the Visual Policy Manager 

This section contains the following topics: 

□ "System Requirements" on page 568 — Discusses the Java Runtime Environment component 
requirement. 

□ "Launching the Visual Policy Manager" on page 570 — Describes how to start VPM from the 
Management Console. 

□ "About the Visual Policy Manager User Interface" on page 571 — Describes VPM menu items, tool 
bars, and work areas. 

□ "About VPM Components" on page 574 — Provides definitions of the policy layers and describes 
how rule objects comprise the layers. 

□ "The Set Object Dialog" on page 577 — Describes the dialog used to select objects to be added or 
edited. 

□ "The Add/Edit Object Dialog" on page 578 — Describes the dialog used to add and edit rule 
objects. 

System Requirements 

Before launching the VPM, verify client computers that are to access the VPM meet the basic 
requirements. 

Supported Operating Systems 

This VPM version supports the following operating systems: 

□ Windows 2000 Professional; SP4 or later 

□ Windows XP; SP 2 or later 

Supported Browsers 

This VPM version supports the following browsers on the supported operating systems: 

□ Internet Explorer 6.0; SP 1 or later 

□ Netscape 7.2 

□ Firefox 1.0 

The VPM might operate on other browsers; however. Blue Coat has not tested other browsers and 
support is not available. 

JRE Requirement 

The VPM requires the Java Runtime Environment Standard Edition (JRE). This VPM version supports 
JRE versions 1.4.1_07 and 5.0 (also listed as 1.5). 
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If a client attempting to start the VPM does not have a valid JRE version, the ProxySG automatically 
connects to the Sun Microsystems download center to begin the download and installation. Follow 
the on-screen instructions to download v5.0 (the default version for this release). 

The VPM is completely independent from the Management Console. If the browser is configured 
properly with its default JRE, the VPM uses the later of the valid versions. 

Notes and Limitations 

□ If you are updating to JRE v5.0. Blue Coat recommends the option to remove any version previous 
to 1.4.1_07 before the update. Removing the obsolete version after updating might cause the 
browser to not recognize v5.0, though it remains installed, and instigate a download prompt. 

□ JRE v5.0: When viewing objects in a drop-down list, you can press a letter key to skip to the first 
object name that starts with that letter. Pressing the same letter cycles to the next object. However, 
immediately pressing another letter key does not take you to the next object if you have not 
waited a few seconds. For example, in searching protocols you can repeatedly press H to cycle 
through the protocols HTTP, HTTPS, and so on, but if you do not wait a short interval to press F to 
go to FTP, no action occurs. 
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Section A: About the Visual Policy Manager 



Launching the Visual Policy Manager 

To launch the VPM: 



1 



Configuration 




® General 
® Network 
® Services 
® External Services 
® Health Checks 
® Authentication 
® Bandwidth Mgmt. 

® Policy 

Policy Options 
Policy Files 

■t>^P^u5[PoiigiMS3fl3il 

Exceptions 

® Content Filtering 
® Forwarding 
® SSL 

® Access Logging 



Visual Policy Manager 



Launch 

A 



[✓ Force Download 



A 



2 



Ensures most current version is launched. 



1. Select Configuration>Policy>Visual Policy Manager. 



2. Click Launch. 



Note: If this is the first time launching the VPM following an OS upgrade, or to ensure you are 

launching the most current VPM version, click Force Download before clicking Launch. 



If a valid JRE is already installed on your workstation, the ProxySG opens a separate browser 
window and starts the VPM. The first time you start the policy editor, it displays an empty policy. 

If a valid JRE is not installed on your workstation, a security warning dialog box appears. Click 
Yes to continue. Follow the instructions to install the JRE. After installation completes, a Launch 
VPM tab briefly displays before the VPM starts. 
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About the Visual Policy Manager User Interface 

The following figure labels VPM components. 



Menu bar 
Toolbar 
Layer tabs 
Object types 
Rules 




Figure 14-6: The VPM components. 



Menu Bar 

The following table describes VPM Menu Bar items. 



Table 14.1: VPM Menu Bar Items 



File 


Install Policy On Proxy SG 


Saves all new policy rules. 




Revert to existing Policy on Proxy SG 


Ignores changes and reloads installed policy rules. 




Exit 


Exits the application. 


Edit 


Add Rule 


Adds a new blank rule to the visible policy layer or 




Delete Rule 


removes a rule from the visible policy layer. 




Cut Rule 
Copy Rule 
Paste Rule 


Standard cut, copy, and paste operations. 




Move Rule Up 
Move Rule Down 


Moves rules up or down one position in a policy layer. 




Disable/Enable Layer 


Disables or enables the selected layer. You can disable 
a layer without removing it from the VPM (thus losing 
composed policy rules) and re-enable it if required. 




Reorder Layers 


Reorders the policy layers. 




Delete Layer 


Deletes a specific policy layer. 


Policy 


Add Admin Authentication Layer 


The Policy menu items add policy layers to be 




Add Admin Access Layer 

Add DNS Access Layer 

Add SOCKS Authentication Layer 

Add SSL Intercept Layer 

Add SSL Access Layer 

Add Web Authentication Layer 

Add Web Access Layer 

Add Web Content Layer 

Add Forwarding Layer 


populated with policy rules. 
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Table 14.1: VPM Menu Bar Items (Continued) 



Configuration 


Set DNS Lookup Restrictions 


Restricts DNS lookups during policy evaluation. 


Set Reverse DNS Lookup Restrictions 


Restricts reverse DNS lookups during policy 
evaluation. 


Set Group Log Order 


Configures the order in which the group information 
is logged. 


Edit Categories 


Edits content filtering categories. 


View 


Generated CPL 


Displays the CPL generated by VPM. 


Current ProxySGVPM Policy Files 


Displays the currently stored VPM policy files. 


Object Occurrences 


Lists the user-created object(s) in the selected rule; lists 
use in other rules as well. 


All Objects 


Displays a dialog that lists current static and 
user-defined VPM objects. You can also create, edit, 
and delete objects. See "Centralized Object Viewing 
and Managing" on page 663. 


Tool Tips 


Toggles the tool-tip display on and off. 


Help 


Help Topics 


Displays the online help. 


About 


Displays copyright and version information. 



Tool Bar 

The VPM Tool Bar contains the following functions: 

□ Add Rule — Adds a blank rule to visible policy layer; all values for the rule are the defaults. 

□ Delete Rule — Deletes the selected rule from the visible policy layer. 

□ Move Up — Moves a rule up one position in the visible policy layer. 

□ Move Down — Moves a rule down one position in the visible policy layer. 

□ Install Policy — Converts the policies created in VPM into Blue Coat Content Policy Language (CPL) 
and installs them on the ProxySG. 
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Policy Layer Tabs 

Every policy layer you create from the Policy>Add Layer menu is displayed as a tab. Click a tab and the 
rules included in that policy layer display below in the main body of the pane. Right-clicking a tab 
displays the options of disable or enabling, renaming, and deleting the policy layer. 



File Edit Policy Configuration View Help 


*p Add Rule ™p Delete Rule 


f Move Up 


4- Move Down 


^ Install Policy 





No. Sc 


Disable Layer ^ 


: ■ 

jn Service 


Time 


Action 


Track 


j 

Comment 




Rename Layer... 
Delete Layer 


^ Methods 1 


Any 


Q Allow 


|None 

















Figure 14-7: Right-click a Policy Tab to Rename or Delete a Policy Layer 
Each VPM policy layer is described in later sections in this chapter. 



Rules and Objects 



A policy layer can contain multiple rules. Every rule is numbered and listed in a separate row. To 
create a new rule, click the Add Rule button; a new rule is added to the bottom of the list. If multiple 
rules exist within a policy layer, the ProxySG finds the first one that matches a given situation and 
ignores the remaining rules. Therefore, rule order is important. Use the Move buttons on the rule bar to 
reorder the rules in a policy. 

Each rule is comprised of objects. The objects are the individual elements of a rule you specify. With 
the exception of No. (number), which indicates the order of the rule in the layer and is filled in 
automatically, all objects are configurable. 

To specify or edit an object setting, position the mouse in the appropriate object cell within a rule and 
right-click to display the drop-down the menu. 



File Edit Policy Configuration View Help 



•p Add Rule 



™p Delete Rule 



-f- Move Up 



4r Move Down 



Install Policy 



Web Access Layer (1) SSL Intercept Layer (1) Admin Access Layer (1) Web Content Layer (1) 



No. 


Source 


Destination 


Service Time 


Action 


Track 


Comment 


1 


^ Authentic... 


Any 


gS IM Messa... |Any 


Efc IM_Alert 


None 




2 


^ 10.1.1.1:80 


U FileExten.. 


Sm^ei 


Q Deny 


□ EventLogl 





Edit... 

Delete 



Negate 



Cut 

Copy 

Paste 



Figure 1 4-8: Right-click a rule cell to set or edit the object properties 

Each object type is described in "Policy Layer and Rule Object Reference" on page 579. 
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About VPM Components 

This section describes the specific policy layer types and rule objects. 

Policy Layers 

The layers are: 

□ Administration Authentication — Determines how administrators accessing ProxySG must 
authenticate. 

□ Administration Access — Determines who can access the ProxySG to perform administration tasks. 

□ DNS Access — Determines how the ProxySG processes DNS requests. 

□ SOCKS Authentication — Determines the method of authentication for accessing the proxy through 
SOCKS. 

□ SSL Intercept — Determines whether to tunnel or intercept HTTPS traffic. 

□ SSL Access — Determines the allow/deny actions for HTTPS traffic. 

□ Web Authentication — Determines whether user clients that access the proxy or the Web must 
authenticate. 

□ Web Access — Determines what clients can and cannot access on the Web and specifies any 
restrictions that apply. 

□ Web Content — Determines caching behavior, such as verification and ICAP redirection. 

□ Forwarding — Determines forwarding hosts and methods. 

As you create policy layers, you will create many different layers of the same type. Often, an overall 
policy requires layers of different types designed to work together to perform a task. For example. 
Authentication and Access layers usually accompany each other; an Authentication layer determines 
if a user or client must authenticate, and an Access layer subsequently determines where that user or 
client can go (what ProxySG or Web sites they can access) once they are authenticated. 

Each object type is described in "Policy Layer and Rule Object Reference" on page 579. 

Rule Objects 

Policy layers contain rule objects. Only the objects available for that policy layer type are displayed. 
There are two types of objects: 

□ Static Objects — A self-contained object that cannot be edited or removed. For example, if you 
write a rule that prohibits users from accessing a specific Web site, the Action object you select is 
Deny. 

Static objects are part of the system and are always displayed. 
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□ Configurable Objects — A configurable object requires parameters. For example, consider the rule 
mentioned in the previous item that prohibits users from accessing a specific Web site. In this case, 
the user is a Source object. That object can be a specific IP Address, user, group, user agent (such as 
a specific browser), and so on. Select one and then enter the required information (such as a 
verifiable user name or group name). 

Configurable objects do not exist until you create them. A created object is listed along with all 
static objects in the list dialog, and you can reuse it in other applicable policy layers. For example, 
an IP address can be a Source or Destination object in many different policy-layer types. 



Important: The orders of policy layers, and the order of rules within a layer are important. For 
more information, see "How Policy Layers, Rules, and Files Interact" on page 673. 



While individual object-type menus occasionally contain entries specific to the object type, the basic 
menu options are: 

□ Allow — (Web Access Layer Action column only) Quick menu access; sets the policy to allow. 

□ Deny — (Web Access Layer Action column only) Quick menu access; sets the policy to deny. 

□ Set — Displays the Set Object dialog where you select an object or create a new one. 

□ Edit — Opens the Edit Object dialog where you edit an object or change to another. 

□ Delete — Removes the selected object from the current rule and restores the default. 

□ Negate — Defined as not. Negate provides flexibility in writing rules and designing the structure of 
policies. The following is a simple Web Access rule that states: "When any client tries to access a 
URL contained in an object of JobSearch, allow access." 



File Edit Policy Configuration View Help 


Add Rule 


Delete Rule 


• f ‘ Move Up 


4- Move Down 


Install Policy 




Web Access Layer (1) 


SSL Intercept Layer (1) 


Admin Access Layer (1) 


Web Content Layer (1) Web Access Layer (2) 




No. Source 


Destination 


Service Time 


Action 


Track Comment 


ltflny 


JobSearchURLs 


Any Any 


Q Allow None 







Figure 14-9: A simple web access policy rule. 

Dragging the pointer to the Destination list, right-clicking to display the drop-down list, and 
clicking Negate invokes a red circle with a horizontal white line in the icon in the cell. 




Figure 14-10: The red icon in the cell indicates negation, or not. 

Now the rule specifies allow all URLs except the ones contained in the JobSearch category object. 
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□ Cut, Copy, and Paste are the standard paste operations with the following restrictions: you can only 
paste anything cut or copied from the same column in the same table and the copy and paste 
functions do not work across multiple layers. 

The following table describes the general function of each object type: 



Object 


Description 


Source 


Specifies the source attribute, such as an IP address, user, or group. 


Destination 


Specifies the destination attribute, such as a URL, IP address, and file extension. 


Service 


Specifies the service attribute, such as protocols, protocol methods, and IM file 
transfer limitations. 


Time 


Specifies day and time restrictions. 


Action 


Specifies what to do when the rule matches. 


Track 


Specifies tracking attributes, such as event log and E-mail triggers. 


Comment 


Optional. You can provide a comment regarding the rule. 



Policy Layer/Object Matrix 

The following table displays which object types are available in each policy layer. 



Policy Layer 


Source 


Destination 


Service 


Time 


Action 


Track 


Comment 


Admin Authentication 


X 








X 


X 


X 


Admin Access 


X 








X 


X 


X 


DNS Access 


X 


X 




X 


X 


X 


X 


SOCKS Authentication 


X 








X 


X 


X 


SSL Intercept 


X 


X 






X 


X 


X 


SSL Access 


X 


X 


X 




X 


X 


X 


Web Authentication 


X 


X 






X 


X 


X 


Web Access 


X 


X 


X 


X 


X 


X 


X 


Web Content 




X 


X 




X 


X 


X 


Forwarding 


X 


X 


X 




X 


X 


X 
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The Set Object Dialog 

This section discusses the Set Object dialog used to select objects for configuration. 

The object rules in all policy layer types determine the conditions for a particular policy rule. 
Depending on the type of policy layer, an object can be anything from a user or group to an IP address 
or a URL and so forth. 

To create a rule, right-click a cell in an object cell. The relevant Set Object dialog displays. In this dialog, 
select the objects for the rule or create new objects as necessary. 

Objects have type-specific icons to provide a visual aid in distinguishing among different types in the 
list. 




Figure 14-11: Set Source Object Dialog with Selectable Objects 

The Set Object dialog only displays or allows you to create the objects allowable in the specific option 
of the rule type you are creating. But if more than one policy-layer type uses the same object type (for 
example, IP address can be a source in rules for four of the five types of policies), then those existing 
objects display in all Set Object dialogs, regardless of policy-layer type. 

Controlling the List of Objects in the Set Object Window 

As you create more policies, it is likely that the lists of existing objects in the various Set Object dialogs 
expand. You can restrict the display of objects in the list to a specific type by selecting an object type 
from the Show drop-down list above the objects field. The following figure demonstrates the window 
displayed above with the list restricted to Client IP addresses. 
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Figure 14-12: Limiting the Set Object Dialog view. 

The Add/Edit Object Dialog 

From the Set Object dialog, the Add Object dialog is used to define configurable objects. Existing 
configurable options can be altered using the Edit Object dialog. In terms of functionality, the two 
dialogs are identical. 

For the initial configuration of an object, click New on the Set Object dialog to display the Add Object 
dialog. Perform the tasks required to configure the object and click OK. The newly named and 
configured object appears in the list of selectable objects in the Set Object dialog and is ready to be 
selected for the rule. 

To edit an existing object, select an object from the list and click Edit. The Edit Object dialog appears 
with the existing parameters on display. Edit as necessary and click OK. 

To remove an existing object, select an object from the list and click Remove. A secondary prompt 
verifies your attempt to remove the object; click OK. The object is deleted. 

Online Help 

The VPM contains its own Plelp module (a porting of this chapter). Each object in the VPM contains a 
Plelp button that links to the corresponding object reference in the Plelp file. This reference describes 
the purpose of the object. Interaction with other policy and references to feature-related sections in the 
Blue Coat ProxySG Configuration and Management Guide are provided, if relevant. Also, this Plelp 
module contains navigation buttons and its own Table of Contents. 



Note: The online Plelp file is displayed in a separate window and requires a few seconds to load 

and scroll to the correct object. The speed of your system might impact this slight lag time. 
Furthermore, this lag time increases on slower machines running JRE vl.5. 
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Section B: Policy Layer and Rule Object Reference 

This section contains the following topics: 

□ "About the Reference Tables" on page 580 — Describes the table conventions used in this section. 

□ "Administration Authentication Policy Layer Reference" on page 580 — Describes the objects 
available in this policy layer. 

□ "Administration Access Policy Layer Reference" on page 580 — Describes the objects available in 
this policy layer. 

□ "DNS Access Policy Layer Reference" on page 581 — Describes the objects available in this policy 
layer. 

□ "SOCKS Authentication Policy Layer Reference" on page 581 — Describes the objects available in 
this policy layer. 

□ "SSL Intercept Layer Reference" on page 582 — Describes the objects available in this policy layer. 

□ "SSL Access Layer Reference" on page 582 — Describes the objects available in this policy layer. 

□ "Web Authentication Policy Layer Reference" on page 583 — Describes the objects available in this 
policy layer. 

□ "Web Access Policy Layer Reference" on page 583 — Describes the objects available in this policy 
layer. 

□ "Web Content Policy Layer Reference" on page 587 — Describes the objects available in this policy 
layer. 

□ "Forwarding Policy Layer Reference" on page 588 — Describes the objects available in this policy 
layer. 
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About the Reference Tables 

The tables in this section list the static and configurable objects available for each policy layer. 



Note: If viewing this document as a PDF, you can click an object name to jump to a description 

of that object (all objects are described in Section C). To jump back to a specific policy 
layer reference, click policy layer name in any object reference table that appears in the 
next section. 



Administration Authentication Policy Layer Reference 

The following table provides the objects available in the Administration Authentication policy layer. 



Source Objects 


Action Objects 


Track Objects 


Client IP Address/Subnet 


Do Not Authenticate 


Trace 


Client Hostname 


Deny 




Proxy IP Address/Port 


Authenticate 




Combined Objects 


Force Authenticate 





Administration Access Policy Layer Reference 

The following table provides the objects available in the Administration Access policy layer. 



Source Objects 


Action Objects 


Track Objects 


Client IP Address/Subnet 


Allow Read-Only Access 


Event Log 


Client Hostname 


Allow Read-Write Access 


Email 


Proxy IP Address/Port 


Deny 


SNMP 


User 


Force Deny 


Trace 


Group 




Combined Objects 


Attribute 






Combined Objects 
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DNS Access Policy Layer Reference 

The following table provides the objects available in the DNS Access policy layer. 



Source Objects 


Destination Objects 


Time Objects 


Action Objects 


Track Objects 


Client IP 
Address/Subnet 


DNS Response 
Contains No Data 


Time 


Bypass DNS 
Cache 


Event Log 


Proxy IP 
Address/Port 


DNS Response IP 
Address/Subnet 


Combined 

Objects 


Do Not Bypass 
DNS Cache 


Email 


DNS Request 
Name 


RDNS Response 
Host 




Allow DNS From 
Upstream Server 


SNMP 


RDNS Request IP 
Address/Subnet 


DNS Response 
CNAME 




Serve DNS Only 
From Cache 


Trace 


DNS Request 
Opcode 


DNS Response Code 




Enable/Disable 
DNS Imputing 


Combined 

Objects 


DNS Request 
Class 


Category 




Send DNS/RDNS 
Response Code 




DNS Request 
Type 


Combined Objects 




Send DNS 
Response 




DNS Client 
Transport 






Send Reverse 
DNS Response 




Combined 

Objects 






Reflect IP 










Manage 

Bandwidth 










Combined Objects 





SOCKS Authentication Policy Layer Reference 

The following table provides the objects available in the SOCKS Authentication policy layer. 



Source Objects 


Action Objects 


Track Objects 


Client IP Address/Subnet 


Do Not Authenticate 


Trace 


Client Hostname 


Authenticate 




Proxy IP Address/Port 


Force Authenticate 




SOCKS Version 






Combined Objects 
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SSL Intercept Layer Reference 

The following table provides the objects available in the SSL Forward Proxy policy layer. 



Source Objects 


Destination Objects 


Action Objects 


Track Objects 


Client Hostname 
Unavailable 


Destination IP 
Address/Subnet 


Set SSL Forward 
Proxy 


Event Log 


Client Hostname 


Destination 

Host/Port 


Combined Objects 


Email 


Proxy IP Address/Port 


Request URL 




SNMP 


Combined Objects 


Request URL Category 




Trace 




Server URL 




Combined Objects 




Server Certificate 








Server Certificate 
Category 








Combined Objects 







SSL Access Layer Reference 

The following table provides the objects available in the SSL Access Layer policy layer. 



Source Objects 


Destination Objects 


Service Objects 


Action Objects 


Track Objects 


Authenticated User 


Destination IP 
Address/Subnet 


Client Protocol 


Allow 


Event Log 


Client Hostname 
Unavailable 


Destination 

Host/Port 


SSL Proxy Mode 


Deny (static) 


Email 


Client IP 
Address/Subnet 


Request URL 


Combined 

Objects 


Deny (Content Filter) 


SNMP 


Client Hostname 


Request URL 
Category 




Require/Do Not 
Require Client 
Certificate 


Trace 


Proxy IP 
Address/Port 


Server URL 




Force Deny 


Combined 

Objects 


User 


Server Certificate 




Force Deny (Content 
Filter) 




Attribute 


Server Certificate 
Category 




Deny 




Client Certificate 


Server Certificate 




Return Exception 
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Source Objects 


Destination Objects 


Service Objects 


Action Objects 


Track Objects 


Client Negotiated 
Cipher 


Server Certificate 
Category 




Set Client Certificate 
Validation 




Client Negotiated 
Cipher Strength 


Server Negotiated 
Cipher 




Set Server 
Certificate Validation 




Client Negotiated 
SSL Version 


Server Negotiated 
Cipher Strength 




Combined Objects 




Combined Objects 


Server Negotiated 
SSL Version 










Combined Objects 





























Web Authentication Policy Layer Reference 

The following table provides the objects available in the Web Authentication policy layer. 



Source Objects 


Destination Objects 


Action Objects 


Track Objects 


Client Hostname 
Unavailable 


Destination IP 
Address/Subnet 


Do Not Authenticate 


Trace 


Client IP 
Address/Subnet 


Destination 

Host/Port 


Deny 




Client Hostname 


Request URL 


Authenticate 




Proxy IP Address/Port 


Request URL Category 


Authentication 

Charset 




User Agent 


Combined Objects 


Force Authenticate 




Request Header 




Combined Objects 




Combined Objects 









Web Access Policy Layer Reference 

The following table provides the objects available in the Web Access policy layer. 

Web Access policy layers regulate, from a general to a granular level, who or what can access specific 
Web locations or content. 

□ Users, groups, individual IP addresses, and subnets, as well as object lists comprised of any 
combination of these, can be subject to rules. 
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□ Rules can include access control for specific Web sites, specific content from any Web site, 
individual IP addresses, and subnets. 

□ Actions taken can range from allowing and denying access to more finely tuned changes or 
limitations. 

□ Rules can also be subject to day and time specifications and protocol, file type, and agent 
delimiters. 



Source Objects 


Destination Objects 


Service Objects 


Time Objects 


Action Objects 


Track Objects 


Streaming Client 


Destination IP 
Address/Subnet 


Using HTTP 
Transparent 
Authentication 


Time 


Allow 


Event Log 


Client Hostname 
Unavailable 


Destination 

Host/Port 


Virus Detected 


Combined 

Objects 


Deny 


Email 










Deny (Content 
Filter) 




Authenticated 

User 


Request URL 


Client Protocol 




Force Deny 


SNMP 










Force Deny 
(Content Filter) 




Client IP 
Address/Subnet 


Request URL 
Category 


Protocol 

Methods 




Bypass Cache 


Trace 


Client Hostname 


File Extensions 


IM File Transfer 




Do Not Bypass 
Cache 


Combined 

Objects 


Proxy IP 
Address/Port 


HTTP MIME Types 


IM Message 
Text 




Check/Do Not 
Check 

Authorization 




User 


Apparent Data Type 


IM Message 
Reflection 




Always Verify 




Group 


Response Code 


Streaming 
Content Type 




Use Default 
Verification 




Attribute 


Response Header 


ICAP Error Code 




Block/Do Not 
Block PopUp 
Ads 




User Agent 


IM Buddy 


Combined 

Objects 




Force/Do Not 
Force IWA for 
Server Auth 




IM User Agent 


IM Chat Room 






Reflect/Do Not 
Reflect IM 
Messages 
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Source Objects 


Destination Objects 


Service Objects 


Time Objects 


Action Objects 


Track Objects 


Request Header 


Combined Objects 






Block/Do Not 
Block IM 
Encryption 












Support/Do Not 
Support 

Persistent Client 
Requests 












Support /Do Not 

Support 

Persistent 

Server 

Requests 




SOCKS Version 








Deny 




IM User 








Return 

Exception 




P2P Client 








Return 

Redirect 




Client Negotiated 
Cipher 








Send IM Alert 




Client Negotiated 
Cipher Strength 








Modify Access 
Logging 




Combined 

Objects 








Override Access 
Log Field 












Rewrite Host 












Reflect IP 












Suppress 

Header 












Control Request 
Header/Control 
Response 
Header 












Notify User 












Strip Active 
Content 












Set Client HTTP 
Compression 
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Source Objects 


Destination Objects 


Service Objects 


Time Objects 


Action Objects 


Track Objects 










Set Server 

HTTP 

Compression 












Set SOCKS 
Compression 












Manage 

Bandwidth 












Modify IM 
Message 












Return ICAP 
Patience Page 












Set External 
Filter Service 












Set ICAP 
Request Service 












Set FTP 
Connection 












Set SOCKS 
Acceleration 












Set Streaming 
Max Bitrate 












Combined 

Objects 





586 



Chapter 14: The Visual Policy Manager 



Section B: Policy Layer and Rule Object Reference 

Web Content Policy Layer Reference 

The following table provides the objects available in the Web Content policy layer. 

The Web Content policy layer applies to requests independent of user identity. 

Content scanning policy layers scan requested URLs and file types for viruses and other malicious 
code. You must have an ICAP service installed on the ProxySG to use this policy type. 



Destination Objects 


Action Objects 


Track Objects 


Destination IP Address/Subnet 


Check/Do Not Check Authorization 


Event Log 


Destination Host/Port 


Always Verify 




Request URL 


Use Default Verification 


Email 


Request URL Category 


Use Default Caching 


SNMP 


File Extensions 


Do Not Cache 


Trace 


HTTP MIME Types 


Force Cache 


Combined Objects 


Response Header 


Mark/Do Not Mark As 
Advertisement 




Combined Objects 


Enable/Disable Pipelining 






Set Dynamic Categorization 






Set External Filter Service 






Set Client HTTP Compression 






Set Server HTTP Compression 






Manage Bandwidth 






Set ICAP Request Service 






Set ICAP Response Service 






Set TTL 






Modify Access Logging 






Override Access Log Field 






Combined Objects 






Support /Do Not Support Persistent 
Server Requests 
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Forwarding Policy Layer Reference 

The following table provides the objects available in the Forwarding policy layer. 



Source Objects 


Destination Objects 


Service Objects 


Action Objects 


Track 

Objects 


Streaming Client 


Destination IP 
Address/Subnet 


Client Protocol 


Send Direct 


Trace 


Authenticated 

User 


Destination 

Host/Port 


Combined Objects 


Integrate/Do Not 
Integrate New Hosts 




Client IP 
Address/Subnet 


Server URL 




Allow Content From 
Origin Server 




Client Hostname 


Combined Objects 




Serve Content Only 
From Cache 




Proxy IP 
Address/Port 






Select SOCKS 
Gateway 




User 






Select Forwarding 




Group 






Reflect IP 




Attribute 






Manage Bandwidth 




SOCKS Version 






Set IM Transport 




P2P Client 






Set SOCKS Gateway 
Compression 




Combined Objects 






Set Streaming 
Transport 










Combined Objects 
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Section C: Detailed Object Column Reference 

This section contains the following topics: 

□ "Source Column Object Reference" 

□ "Destination Column Object Reference" 

□ "Service Column Object Reference" 

□ "Time Column Object Reference" 

□ "Action Column Object Reference" 

□ "Track Object Column Reference" 

□ "Comment Object Reference" 

□ "Using Combined Objects” 

□ "Creating Categories" 



Source Column Object Reference 

A source object specifies the communication or Web transaction origin that is evaluated by the policy. 
Not all policy layers contain the same source objects. 



Important: Because of character limitations required by the generated CPL, only alphanumeric, 
underscore, dash, ampersand, period, or forward slash characters can be used to 
define a source object name. 



Any 

Applies to any source. 

Streaming Client 

This is a static object. This rule applies to any request from a streaming client. 

Client Hostname Unavailable 

This is a static object. This rule applies if the client IP address could not be looked up with a reverse 
DNS query. 

Authenticated User 

This is a static object. This rule applies to any authenticated user. 
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Client IP Address/Subnet 

Specifies the IP address and, optionally, a subnet mask of a client. The policy defined in this rule 
applies only to this address or addresses on this subnet. This object is automatically named using the 
prefix Client; for example. Client: 1 .2.0.0/255.255.0.0. 



Note: See "Combined Source Object" on page 602 for related information regarding this source 

object. 



Client Hostname 

Specifies a reverse DNS hostname resolved in the reverse lookup of a client IP address. Enter the host 
name and select matching criteria. This object is automatically named using the prefix Client; for 
example. Client: host.com. If you select a matching qualifier, that attribute is appended to the object in 
parentheses. For example. Client: host.com (RegEx). 

Proxy IP Address/Port 

Specifies the IP address and, optionally, a port on the ProxySG. The policy defined in this rule applies 
only to this address or addresses with this subnet. 

User 

Specifies an individual user in the form of a verifiable username or login name. Enter a user name and 
an authentication realm. The dialog then displays different information depending on the type of 
authentication realm specified. Select the appropriate realm from the drop-down list. Items in the list 
are taken from the realms configured by the administrator in the ProxySG. 

LDAP 

You can optionally select a User Base DN from a drop-down list. Entries in the User Base DN list come 
from those specified by the administrator in the ProxySG. You can also edit an entry selected in the 
list, or type a new one. Edited names and new names are retained in the list. Notice in the Full Name 
field that VPM takes the User Attribute type specified by the administrator in the ProxySG (cn= in the 
following illustration), and associates it with the user name and Base DN entered here. 



Important: When you configure a realm, the ProxySG assumes a default primary user attribute 
(sAMAccountName for Active Directory; uid for Netscape/iPlanet Directory 
Server /SunOne; on for Novell NDS). You can accept the default or change it. 
Whatever is entered there is what VPM uses here, entering it in the Full Name display 
field once a Base DN is selected. 



If the primary user attribute specified in the ProxySG differs from the primary user attribute specified 
in the directory server, enter the latter in the User field with the appropriate value (in the format 
attribute=value). This replaces the entry in the Full Name field. Examine the following screenshot. 
Assume that the organization uses phone as the primary attribute in its LDAP directory: 
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You can only enter a 
user attribute and 
equal sign in the 
User field if a User 
Base DN is 
selected. 



Figure 14-13: Specifying an LDAP primary user attribute 
IWA 

Entries in this list are not prepopulated. You must enter a name in the Domain Name field. An entered 
name is retained and can subsequently be selected and edited. Notice in the Full Name field that VPM 
displays domain name and user name entered above. 
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Figure 14-14: Adding an IWA User with a FQDN or DN 
RADIUS 

Entries in this list are not prepopulated. You must enter a name in the User field. An entered name is 
retained and can subsequently be selected and edited. Notice in the Full Name field that VPM displays 
domain name and user name entered above. 

Windows SSO 

Entries in this list are not prepopulated. You must enter a name in the User field. Entries in the Domain 
Name list come from those specified by the administrator in the ProxySG. You can also edit an entry 
selected in the list, type a new one, or click Browse to manually select a name. 

Local 

Entries in this list are not prepopulated. You must enter a name in the User field. An entered name is 
retained and can subsequently be selected and edited. Notice in the Full Name field that VPM displays 
domain name and user name entered above. 

Certificate 

If a Certificate realm is selected and that realm uses an LDAP realm as authentication realm, the 
Browse button is clickable. This option allows you to browse the LDAP database and select users, thus 
preventing typing errors possible from manually entering names in the fields. If the Certificate realm 
does not use an LDAP authentication realm. Browse is not displayed. 
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Netegrity SiteMinder 

Entries in this list are not prepopulated. You must enter a name in the User field. An entered name is 
retained and can subsequently be selected and edited. Notice in the Full Name field that VPM displays 
domain name and user name entered above. 

Oracle COREid 

Entries in this list are not prepopulated. You must enter a name in the User field. An entered name is 
retained and can subsequently be selected and edited. Notice in the Full Name field that VPM displays 
domain name and user name entered above. 

Policy Substitution 

Entries in this list are not prepopulated. You must enter a name in the User field. An entered name is 
retained and can subsequently be selected and edited. Notice in the Full Name field that VPM displays 
domain name and user name entered above. 

Sequences 

Entries in this list are not prepopulated. You must enter a name in the User field. An entered name is 
retained and can subsequently be selected and edited. Notice in the Full Name field that VPM displays 
domain name and user name entered above. From the Member Realm drop-down list, select an 
authentication realm (already configured on the ProxySG). Depending on the realm type, new fields 
appear. 

Group 

Specifies a verifiable group name. Enter a user group and an authentication realm. The dialog then 
displays different information depending on the type of authentication realm specified. 

□ Group field — Replace the default with a verifiable group name. 

□ Authentication Realm field — Select the appropriate realm from the drop-down list. Items in the list 
are taken from the realms configured by the administrator in the ProxySG. 

• LDAP — Entries in the Group Base DN list come from those specified by the administrator in the 
ProxySG. You can also edit an entry selected in the list, or type a new one. Edited names and 
new names are retained in the list. Notice in the Full Name field that the VPM takes the User 
Attribute type specified by the administrator in the ProxySG (cn= in the following 
illustration), and conjoins it with the group name and Base DN entered here. 



Important: When you create a group, the default attribute is cn= in the Full Name display 

field. 
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Figure 14-15: Creating an LDAP Group Object 

If the primary user attribute specified in the ProxySG differs from the primary user attribute 
specified in the directory server, you need to enter the latter here. Do that by typing it in the 
Group field with the appropriate value (in the format attribute=value). Doing so replaces the 
entry in the Full Name field. Unlike the comparable situation when creating a user (described 
immediately above), when creating a group, the Group Base DN does not need to be selected in 
order to type the attribute=value pair in the Group field. 

• IWA — Entries in this list are not prepopulated. You must enter a name in the Domain Name 
field. A name typed in is retained and can subsequently be selected and edited. Notice in the 
Full Name field that VPM displays the domain name and group name entered above. 

• RADIUS — Entries in this list are not prepopulated. You must enter a name in the Group field. 
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Figure 14-16: Creating an IWA group object. 

• Windows SSO — Entries in this list are not prepopulated. You must enter a name in the Group 
field. 

• Local — Entries in this list are not prepopulated. You must enter a name in the Group field. A 
name typed in is retained and can subsequently be selected and edited. Notice in the Full 
Name field that VPM displays the group name entered above. 

• Certificate — If a Certificate realm is selected and that realm uses an LDAP realm as 
authentication realm, the Browse button is clickable. This option allows you to browse the 
LDAP database and select users, thus preventing typing errors possible from manually 
entering names in the fields. If the Certificate realm does not use an LDAP authentication 
realm. Browse is not displayed. 

• Netegrity SiteMinder — Entries in this list are not prepopulated. You must enter a name in 
the Group field. A name typed in is retained and can subsequently be selected and edited. 
Notice in the Full Name field that VPM displays the group name entered above. 

• Oracle COREid — Entries in this list are not prepopulated. You must enter a name in the 
Group field. A name typed in is retained and can subsequently be selected and edited. 
Notice in the Full Name field that VPM displays the group name entered above. 

• Policy Substitution — Entries in this list are not prepopulated. You must enter a name in the 
Group field. A name typed in is retained and can subsequently be selected and edited. 
Notice in the Full Name field that VPM displays the group name entered above. 
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• Sequences — Entries in this list are not prepopulated. You must enter a name in the Group 

field. An entered name is retained and can subsequently be selected and edited. Notice in 
the Full Name field that VPM displays domain name and user name entered above. From 
the Member Realm drop-down list, select an authentication realm (already configured on 
the ProxySG). Depending on the realm type, new fields appear. 



Attribute 

Specifies an LDAP or Radius realm-specific attributes. 

LDAP 

Specifies a specific LDAP attribute (and optional value). 

To specify an LDAP attribute: 




1. In the Name field, enter a name for the object or leave as is to accept the default. 

2. From the Authentication Realm drop-down list, select All LDAP or a specific realm. 

3. In the Attribute Name field, enter a valid attribute. 

4. In the Attribute Value field, enter value for the specified LDAP attribute, or leave blank to accept 
any value. 

The above example sets a Common Name (CN) attribute with the value of Kent to the LDAP1 realm. 

RADIUS 

Specifies a RADIUS attribute. 
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To specify a RADIUS attribute: 




1. In the Name field, enter a name for the object or leave as is to accept the default. 

2. Select All RADIUS or a specific realm. 

3. Select an Attribute Name. 

4. Enter an Attribute Value for the Attribute Name. 

DNS Request Name 

Specifies a DNS request. Enter the host name and select matching criteria. This object is automatically 
named using the prefix DNS; for example, DNS: host.com. If you select a matching qualifier, that 
attribute is appended to the object in parentheses. For example, DNS: host.com (RegEx). 

RDNS Request IP Address/Subnet 

Specifies the reverse DNS IP address and, optionally, a subnet mask. The policy defined in this rule 
applies only to this address or addresses on this subnet. This object is automatically named using the 
prefix RDNS; for example, RDNS: 5.6.0.0/255.255.0.0. 

DNS Request Opcode 

Specifies OPCODES to represent in the DNS header. 

To Specify a DNS Request OPCODE Object 

1. In the Name field, enter a custom name or leave as is to accept the default. 

2. Select one or more of the OPCODES. 

3. Click OK. 
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DNS Request Class 

Specifies the DNS request class (QCLASS) properties. 

To specify a DNS Request Class object: 

1. In the Name field, enter a custom name or leave as is to accept the default. 

2. Select one or more of the request classes. 

3. Click OK. 

DNS Request Type 

Specifies the DNS request types (QTYPE) attributes. 

To specify a DNS Request Type object: 

1. In the Name field, enter a custom name or leave as is to accept the default. 

2. Select one or more of the request types. 

3. Click OK. 

DNS Client Transport 

Specifies the DNS client transport method, UDP or TCP. 

To specify a DNS Client Transport object: 

1. Select UDP Transport or TCP Transport. This object is automatically named using the prefix DNS; for 
example, DNS: Client Transport UDP. 

2. Click OK. 

SOCKS Version 

Specifies the SOCKS version, 4 or 5. This object is automatically named as SOCKSVersion4 or 
SOCKSVersion5. 

User Agent 

Specifies one or more agents a client might use to request content. The choices include specific 
versions of: Microsoft Internet Explorer, Netscape Communicator, Microsoft Windows Media Player 
and NetShow, Real Media RealPlayer and RealDownload, Apple QuickTime, Opera, and Wget. 

The policy defined in this rule applies to these selected agents. You can name this list and create other 
custom lists to use with other policy layer rules. 
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Example: selecting 

streaming media > 

user agents. 




Note: If you require a user agent not contained in this list, use the Request Header object, which 

can contain user agent specified as a header. 



IM User Agent 

Checks the specified string for a match in the user agent provided by the IM client. For example, 
specify the string Lotus to distinguish between the Lotus AOL client and the standard AOL client. 

To specify a header: 

1. In the IM User Agent field, enter a string. 

2. From the drop-down list, select a matching criteria. 

3. Click Add. 

Request Header 

Specifies the rule applies to requests containing a specific header. Blue Coat supplies a list of standard 
headers, but you can also select a custom header. 
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To specify a request header: 




1. In the Name field, enter a custom name or leave as is to accept the default. 

2. From the Show drop-list select the viewing field from All to Standard or Custom, as desired. Standard 
displays only the default standard headers. Custom displays any admin-defined headers that exist. 

3. From the Header Name drop-list, select a standard or custom header or enter a new custom header 
name. 

4. In the Header Regex field, enter the header values to which this rule applies. 

Client Certificate 

Allows for testing common name and subject fields in client certificates. 



IM User 

Specifies an IM user by their handle. IM traffic sent to or from this user is subject to this rule. You can 
enter a complete user ID, a string that is part of a user ID, or a string with a regular expression. Select 
the match type from the drop-down list to the right (Exact, Contains, or RegEx). 



Example: 
Designating 
Bob Kent in 
Purchasing 
as IM user 
number 1 . 




600 





Chapter 14: The Visual Policy Manager 



Section C: Detailed Object Column Reference 

P2P Client 

Specifies peer-to-peer (P2P) clients. 

To specify P2P Clients: 

1. In the Name field, enter a name for the object or accept the default. 

2. Select All P2P Clients (all protocols become selected), or one or more P2P protocols. 

3. Click OK. 

Client Negotiated Cipher 

Allows the testing of the SSL cipher in use between the ProxySG and the browser. 

To specify a Client Negotiated Cipher: 

1. In the Name field, enter a name for the object or accept the default. 

2. Select one or more cipher codes valid for this rule. 

3. Click OK. 

Client Negotiated Cipher Strength 

Tests the cipher strength between a Proxy SG-to-browser (client) HTTPS connection. 

To specify a Client Negotiated Cipher Strength: 

1. In the Name field, enter a name for the object or accept the default. 

2. Select one or more of the strength options valid for this rule: Export, High, Medium, Low. 

3. Click OK. 

Low, Medium, and High strength ciphers are not exportable. 

Client Negotiated SSL Version 

Tests the SSL version between a ProxySG-to-browser (client) HTTPS connection. 

To specify a Client Negotiated SSL Version: 

1. In the Name field, enter a name for the object or accept the default. 

2. Select one or more of the version options valid for this rule: SSL 2.0, SSL 3.0, or TLS 1 .0. 

3. Click OK. 
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Combined Source Object 

Allows you to create an object that combines different source types. Refer to "Using Combined 
Objects" on page 660. 



Note: Blue Coat strongly recommends that combined objects with large lists of Client IP 

Address/Subnet values (see "Client IP Address /Subnet” on page 590) do not contain 
other source objects. If other source objects are present, the policy evaluation might 
experience a significant performance degradation. 



Source Column/Policy Layer Matrix 

The following matrix lists all of the Source column objects and indicates which policy layer they apply 
to. 



Object 


Admin 

Auth 


Admin 

Access 


DNS 

Access 


SOCKS 

Auth 


SSL 

Intercept 


SSL 

Access 


Web 

Auth 


Web 

Access 


Web 

Content 


Forwarding 


Streaming Client 
















X 






Client Hostname 
Unavailable 










X 


X 


X 


X 






Authenticated User 












X 




X 




X 


Client IP Address/Subnet 


X 


X 


X 


X 


X 


X 


X 


X 




X 


Client Hostname 


X 






X 


X 


X 


X 


X 




X 


Proxy IP Address/Port 


X 


X 


X 


X 


X 


X 


X 


X 




X 


User 




X 








X 




X 




X 


Group 




X 








X 




X 




X 


Attribute 




X 








X 




X 




X 


DNS Request Name 






X 
















RDNS Request IP 
Address/Subnet 






X 
















DNS Request Opcode 






X 
















DNS Request Class 






X 
















DNS Request Type 






X 
















DNS Client Transport 






X 
















SOCKS Version 








X 








X 




X 


User Agent 














X 


X 
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Object 


Admin 

Auth 


Admin 

Access 


DNS 

Access 


SOCKS 

Auth 


SSL 

Intercept 


SSL 

Access 


Web 

Auth 


Web 

Access 


Web 

Content 


Forwarding 


IM User Agent 
















X 






Request Header 














X 


X 






Client Certificate 












X 










IM User 
















X 






P2P Client 
















X 




X 


Client Negotiated Cipher 












X 




X 






Client Negotiated Cipher 
Strength 












X 




X 






Client Negotiated SSL 
Version 












X 










Combined Objects 


X 


X 


X 


X 


X 


X 


X 


X 




X 



Destination Column Object Reference 

A destination object specifies the communication or Web traffic destination that is evaluated by the 
policy. Not all policy layers contain the same destination objects. 



Important: Because of character limitations required by the generated CPL, only alphanumeric, 
underscore, dash, ampersand, period, or forward slash characters can be used to 
define a destination object name. 



Any 

Applies to any destination. 

DNS Response Contains No Data 

This is a static object. 

Destination IP Address/Subnet 

Specifies the IP address and, optionally, a subnet mask of a destination server. The policy defined in 
this rule only applies to this address only or addresses within this subnet. This object is automatically 
named using the prefix Destination; for example. Destination: 1 .2.0.0/255.255.0.0. 
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Destination Host/Port 

Specifies the hostname or port of a destination server. The policy defined in this rule applies to this 
host on this port only. Enter the host name and port number, and select matching criteria. This object is 
automatically named using the prefix Destination; for example. Destination: company.com:80. 



Request URL 

Applies to a URL request sent by the client to the ProxySG. 



To check for a match against requested URL: 



Select an option and enter the required information in the fields: 



□ Simple Match — Matches a partial URL. If a host name is specified, all hosts in that domain or 

subdomain match; if a path is specified, all paths with that path prefix match; if a scheme or port 
number is specified, only URLs with that scheme or port match. This object is automatically 
named using the prefix URL; therefore, the object is displayed in the rule as URL: host.c om. 



© 



-Simple Match 



URL: www.gambling.com 



If the host specified is a domain name, all hosts in that domain (or any subdomain) will match. If 
a path is specified, all paths with that prefix will match. If a scheme or port number is specified, 
only URLs with that scheme or port will match. 



□ Regular Expression Match — Specifies a regular expression. This object is automatically named using 

the prefix URL; therefore, the object is displayed as URL: host.com (RegEx). 



® 



-Regular Expression Match 

RegEx: http://www.example.com/*. doc j 



□ Advanced Match — Specifies a scheme (protocol), host, port range, and / or path. Unlike the other 
options on this dialog, selecting Advanced Match allows you to enter a name at the top of the dialog 
to name the object. With host and path, you can select from the drop-down list to match exactly as 
entered or parts thereof: Exact Match, Contains, At Beginning, At End, or RegEx. If you select a 
matching qualifier, that attribute is appended to the object in parentheses. For example, URL: 
host.com (Contains). 
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Request URL Category 

Allows you to create and customize categories of URLs. Requested URLs are checked for matches and 
categorized and evaluated for further action dependent upon content filtering policy. 

□ Policy — Displays all current pre-defined and user created URL categories. This includes all 
category-related configurations created in the VPM, as well as in the Local and Central policy files 
(once installed). Select and deselect categories as required. 

You can also create new categories from this dialog, which is similar to the dialog accessed 
through the VPM Menu Bar as described in "Creating Categories" on page 666. 

If you enable a service, such a content filter, those relevant categories appear in this object. 

□ Blue Coat — If you are employing Blue Coat Web Filter, those categories appear here. 

□ System — Displays hard-coded ProxySG configurations. These are not editable, but you can select 
or deselect them. 
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To create a policy category: 

1. Select Policy; click Add. The Object Name dialog appears. 

2. Name the category and click OK. 

3. Drop the Policy list and select the created category; click Edit URLs. The Edit Locally Defined 
Category Object dialog appears. 

4. Enter URLs appropriate for the content filter category you are creating; click OK. 

5. Click OK. 



Note: If one or more other administrators have access to the ProxySG through other 

workstations and are creating categories either through VPM or with inline commands, 
consider that newly-created or edited categories are not synchronized until the policy is 
installed. When the policy is installed with VPM, the categories are refreshed. If confusion 
occurs, select the File>Revert to Existing Policy on ProxySG Appliance option to restore the 
policy to the previous state and reconfigure categories. 



Category Hierarchy Behavior 

Once categories have been created, they can be selected and deselected as required. If you create 
sub-categories (a parent and child category hierarchy), the category selection behavior is the 
following: 

□ Selecting a parent category automatically selects all child categories if no child categories are 
already selected. 



Categories 

[^-Policy 

|— E_Staff 

□- p lIPBnSH 

t p JobSearchTrack 
p Competitors 



□ Deselecting a parent category automatically deselects all child categories if all child categories are 
already selected. 

□ If one or more of the child categories are already selected or deselected, selecting or deselecting 
the parent category does not affect child categories — the status of selected or deselected remains 
the same. 
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This behavior applies to as many levels as you create. 

Category 

Functions the same as "Request URL Category", but this object is unique to the DNS Access Layer. 

Server URL 

This object is functions the same as the "Request URL" object, but applies to a URL sent from the 
ProxySG to a server. If the ProxySG is performing URL rewrites, the URL sent from the client might 
change, which requires another URL matching check. 

Server Certificate 

Allows testing of server certificate attributes to be used by the ProxySG-to-server FITTPS connections. 
Select one of the options: 

□ Hostname: This is the hostname you want to match in the server certificate. After you enter the 
hostname, select from the dropdown list one of the following: Exact Match, Contains, At Beginning, At 
End, Domain, or Regex. 

□ Subject: This is the fully qualified subject name in the server certificate. After you enter the subject, 
select from the dropdown list one of the following: Exact Match, Contains, At Beginning, At End, 
Domain, or Regex. 

Server Certificate Category 

Functions the same as the "Request URL Category" object, but the piece of information used for 
matching and categorizing is the hostname in the server certificate. 

Server Negotiated Cipher 

Tests the cipher suites used in a ProxySG-to-server connection. 

To specify a Server Negotiated Cipher: 

1. In the Name field, enter a name for the object or accept the default. 

2. Select one or more cipher codes valid for this rule. 

3. Click OK. 
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Server Negotiated Cipher Strength 

Specifies the cipher strength between a ProxySG-to-server HTTPS connection. 

To specify a Server Negotiated Cipher Strength: 

1. In the Name field, enter a name for the object or accept the default. 

2. Select one or more of the strength options valid for this rule: Export, High, Medium, or Low. 

3. Click OK. 

Low, Medium, and High strength ciphers are not exportable. 

Server Negotiated SSL Version 

Specifies the SSL version between a ProxySG-to-server HTTPS connection. 

To specify a Server Negotiated SSL Version: 

1. In the Name field, enter a name for the object or accept the default. 

2. Select one or more of the version options valid for this rule SSL 2.0, SSL 3.0, or TLS 1 .0. 

3. Click OK. 

File Extensions 

Creates a list of file extensions. The rule is triggered for content with an extension matching any on the 
list. You can create multiple lists that contain various extensions to use in different rules. For example, 
create a list called Images, and select file extension types such as GIF, JPEG, BMP, XPM, and so on. 

HTTP MIME Types 

Creates a list of HTTP MIME content types. The rule is triggered for content matching any on the list. 
You can create multiple lists that contain various MIME types to use in different rules. For example, 
create a list called MicrosoftApps, and select MIME types application/vnd.ms-excel, 
application/vnd.ms-powerpoint, application/vnd. ms-project, and application/vnd. works. 



Note: If you require a MIME type not contained in this list, use a Request URL object that uses 

the At End matching criteria. 
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Apparent Data Type 

The options in this object identify data content associated with Microsoft DOS and Windows 
executable files. When used in a deny policy, the purpose of this object to deny executable downloads 
and block drive-by installation of spyware. 

To specify Apparent Data Type: 

1. In the Name field, enter a name for the object or accept the default. 

2. Select one or both of the following data types: 

• DOS/Windows Executable: Any type of Windows executable file, such as . exe files (the most 
common type of Microsoft executable file, which is self-extracting); . dll files (also 
self-extracting, but require another executable file), and . ocx files (ActiveX control files that 
can be installed if the browser security level is set to low). Windows PE, LE, and NE 
executable types are recognized. 

• Microsoft Cabinet File: Although not executable themselves, . cab (cabinet) files are used by 
spy wa re programs to propagate ActiveX controls. Code in HTML pages reference . cab files, 
which, from the inside, instruct the browser to download and extract ActiveX components. 

3. Click OK. 

Response Code 

Specifies the rule applies to content responses containing a specific HTTP code. Select a code from the 
drop-down list. You can name the rule object or accept the default name. 

Response Header 

Specifies the rule applies to content responses containing a specific header. Blue Coat supplies a list of 
standard headers, but you can also enter a custom header. 
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To specify a header: 



1 

2 

3 

4 




1. In the Name field, enter a custom name or leave as is to accept the default. 

2. From the Show drop-down list select the viewing field from All to Standard or Custom, as desired. 
Standard displays only the default standard headers. Custom displays any admin-defined headers 
that exist. 



3. From the Header Name drop-down list, select a standard or custom header. 

4. In the Header Regex field, enter the header string this rule applies to. 



IM Buddy 

Specifies an IM buddy by their handle. IM traffic sent to or from this buddy is subject to this rule. You 
can enter a complete buddy ID, a string that is part of a buddy ID, or a string with a regular 
expression. Select the match type from the drop-down list to the right (Exact, Contains, or RegEx). 

IM Chat Room 

Specifies an IM chat room by name or other triggers. IM traffic sent to this chat room is subject to this 
rule. 
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To create a chat room trigger: 




2b 



2c 



1. In the Name field, enter a name for the object or leave as is to accept the default. 

2. Select one or more of the following triggers: 

a. Room ID — Specifies a specific IM chat room by its name. Enter a name and from the 
drop-down list select an option: Exact Match, Contains, or RegEx. 

b. Type — Specifies whether the room is Private or Public. 

c. Invite Only — Specifies to trigger if user must be invited or not. 

d. Voice Enabled — Specifies whether room supports voice chat or not. 

e. Conference — Specifies whether room has conference capability or not. 



3. Click OK. 



DNS Response IP Address/Subnet 

Specifies the destination DNS IP address and, optionally, a subnet mask. The policy defined in this 
rule only applies to DNS responses containing this address or addresses within this subnet. This 
object is automatically named using the prefix DNS; for example, DNS: 1 .2.3.4/255.255.0.0. 



RDNS Response Host 

Specifies a reverse DNS response hostname resolved in the reverse lookup of a client IP address. Enter 
the host name and select matching criteria. This object is automatically named using the prefix RDNS; 
for example, RDNS: host.com. If you select a matching qualifier, that attribute is appended to the object 
in parentheses. For example, RDNS: host.com (RegEx). 
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DNS Response CNAME 

Specifies the rule applies to DNS CNAME responses matching a given hostname. Enter the host name 
and select matching criteria. This object is automatically named using the prefix DNS CNAME; 
therefore, the object is displayed as DNS CNAME: host.com. 

DNS Response Code 

Specifies the rule applies to DNS responses containing a specific DNS Response code. Select one or 
more codes from the list. You can name the rule object or accept the default name. 

Combined Destination Objects 

Allows you to create an object that combines different destination types. Refer to "Using Combined 
Objects” on page 660. 

Destination Column/Policy Layer Matrix 

The following matrix lists all of the Destination column objects and indicates which policy layer they 
apply to. 



Object 


Admin 

Auth 


Admin 

Access 


DNS 

Access 


SOCKS 

Auth 


SSL 

Intercept 


SSL 

Access 


Web 

Auth 


Web 

Access 


Web 

Content 


Forwarding 


Destination IP 
Address/Subnet 










X 


X 


X 


X 


X 


X 


Destination Port 










X 


X 


X 


X 


X 


X 


Request URL 










X 


X 


X 


X 


X 


X 


Request URL Category 










X 


X 


X 


X 


X 




Category 






X 
















Server URL 










X 


X 










Server Certificate 










X 


X 










Server Certificate Category 










X 


X 










Server Negotiated Cipher 












X 










Server Negotiated Cipher 
Strength 












X 










Server Negotiated SSL 
Version 












X 










File Extensions 
















X 


X 




HTTP MIME Types 
















X 


X 
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Object 


Admin 

Auth 


Admin 

Access 


DNS 

Access 


SOCKS 

Auth 


SSL 

Intercept 


SSL 

Access 


Web 

Auth 


Web 

Access 


Web 

Content 


Forwarding 


Apparent Data Type 












X 










Response Header 
















X 






Response Code 
















X 






IM Buddy 
















X 






IM Chat Room 
















X 






DNS Response IP 
Address/Subnet 






X 
















RDNS Response Host 






X 
















DNS Response CNAME 






X 
















DNS Response Code 






X 
















Combined Objects 






X 








X 


X 


X 


X 



Service Column Object Reference 

A service object specifies a service type, such as a protocol, that is evaluated by the policy. Not all 
policy layers contain the same service objects. 



Important: Because of character limitations required by the generated CPL, only alphanumeric, 
underscore, dash, ampersand, period, or forward slash characters can be used to 
define a service object name. 



Any 

Applies to any service. 

Using HTTP Transparent Authentication 

This is a static object. The rule applies if the service is using HTTP transparent authentication. 

Virus Detected 

This is a static object. The rule applies if ICAP scanning detects a virus. 

Client Protocol 
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Specifies the client protocol types and subsets. From the first drop-down list, select a type from the 
drop-down list: Endpoint Mapper, FTP, HTTP, HTTPS, Instant Messaging, P2P, Shell, SOCKS, SSL, 
Streaming, or TCP Tunneling. 
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The second drop-down list allows you to select a protocol subset (these options vary depending on 
the selected protocol): 

□ All — Applies to all communication using this type of protocol. 

□ Pure — Applies if the protocol is using a direct connection. 

□ Over — Applies if a protocol is communicating through a specific transport method. 

□ Unintercepted SSL — Applies to SSL traffic that is not intercepted. 

Protocol Methods 

Specifies the protocol methods that trigger a rule. 

To specify a protocol method: 




1. In the Name field, enter a name or accept the default. 

2. From the Protocol drop-down list, select one of the options: FTP, HTTP, HTTPS, Instant Messaging, 
SOCKS. 

3. Select connection methods. These options vary depending on the selected protocol. The above 
example demonstrates basic Instant Messaging connections. 

4. Click OK. 
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SSL Proxy Mode 

Specifies the deployment mode of the SSL proxy: HTTPS Forward Proxy requests, HTTPS Reverse Proxy 
requests. Unintercepted SSL requests. This objects allows you to apply policy to a subset of SSL traffic 
going through the ProxySG. For example, this object can be used to enforce strong cipher suites for 
HTTPS reverse proxy requests while, allowing all ciphers suites for HTTPS forward proxy requests. 

IM File Transfer 

Specifies the rule is applied to IM file transfers, which can be triggered by matching the file name, file 
size, or both. 

To specify IM file transfer parameters: 




2a 



2b 

3b 



3a 



1. In the Name field, enter a name for the object or accept the default. 

2. To trigger by file name: 

a. Select File; in the File field, specify a file name; 

b. From the drop-down list, select if file is matched exactly (Exact Match), if the file contains 
the name (Contains), or matched by regular expression (RegEx). 

3. To trigger by message size: 

a. Select Size and enter a range. 

b. From the drop-down list, select the size attribute: Bytes, Kbytes, MBytes, or GBytes. 

IM Message Text 

Specifies the rule is applied to IM message text, which can be triggered by any or all of the following: 
matching content keywords, message size, service type, and whether the content type is text or 
application. 
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To specify IM message text parameters: 




2b 



2a 



3b 



1. In the Name field, enter a name for the object or accept the default. 

2. To trigger by content keywords: 

a. Select Text; in the Text field, specify a keyword. 

b. From the drop-down list, select if the file contains the text (Contains), or if it is to be 
matched by regular expression (RegEx). 

3. To trigger by message size: 

a. Select Size; enter a range. 

b. From the drop-down list, select the size attribute: Bytes, Kbytes, MBytes, or GBytes. 

4. To specify the message route, select Route. From the drop-down list, select Service, Direct, or Chat. 

5. To specify message type, select Text or Application. 

• Text specifies messages entered by a user. 

• Application specifies messages sent by the client application, such as typing notifications. 

IM Message Reflection 

Allows policy to test whether or not reflection is enabled for the current message and, if enabled, 
whether it is possible. 

□ Succeeded — IM reflection is enabled and is performed for this message. 

□ Failed — IM reflection is enabled, but not possible for this message because the recipient is not 
connected through this ProxySG. 

□ Disabled — IM reflection is not enabled for this message. 

The objects are automatically named based on the selection and can be used in any rule. 
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Streaming Content Type 

Specifies streaming protocols. 

To specify streaming protocols: 

1. In the Name field, enter a name for the object or accept the default. 

2. Select All Streaming Content (all protocols become selected), or one or more streaming protocols. 

3. Click OK. 

ICAP Error Code 

Defines an object that recognizes one or more ICAP error codes returned during an antivirus scan. The 
rule applies if the scan returns the specified errors. 

To specify ICAP error codes: 




2a 



2b 



2c 



1. In the Name field, enter a name for the object or accept the default. 

2. Select an option: 
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a. No errors — An ICAP scan was performed without scanning errors. 

b. Any errors — An ICAP error code was returned during a scan. 

c. Selected errors — An ICAP error code of a specific type or types. In the Available Errors field, 
select one or more ICAP error codes (press and hold the Control key to select more than 
one type or the Shift key to select a block of types). Click Add. 

3. Click OK. 

Combined Service Objects 

Allows you to create an object that combines different service types. Refer to "Using Combined 
Objects" on page 660. 

Service Column/Policy Layer Matrix 

The following matrix lists all of the Service column objects and indicates which policy layer they apply 
to. 



Object 


Admin 

Auth 


Admin 

Access 


DNS 

Access 


SOCKS 

Auth 


SSL 

Intercept 


SSL 

Access 


Web 

Auth 


Web 

Access 


Web 

Content 


Forwarding 


Using HTTP Transparent 
Authentication 
















X 






Client Protocol 












X 




X 


X 


X 


Protocol Methods 
















X 


X 


X 


SSL Proxy Mode 












X 










IM File Transfer 
















X 






IM Message Text 
















X 






IM Message Reflection 
















X 






Streaming Content Type 
















X 






ICAP Error Code 
















X 






Combined Objects 












X 




X 


X 


X 



Time Column Object Reference 

A time object specifies a block of time or time trigger that determines client access regarding other 
parameters in the rule (such Web sites and content types). Currently, the Time object is only applicable 
to the Web Access Layer. 

Any 

Applies anytime. 
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Time 



Specifies the time restrictions. 

To configure time restrictions: 



Add Time Object 






-C =- Name: 



Timel 



- >0 Use Local Time Zone 
Use UTC Time Zone 

pOnly between the following times of day: 
From: 38 ^ : I®} * 



““£>-0 Enable 



H>0 Enable 



*" 0 Enable 



- 0 Enable 



Enable 



-Only on the following days of the week: 



0 Monday 
0 Friday 



0 Tuesday 
| | Saturday 



To: 16 „ : 59 „ 



0 Wednesday 
| | Sunday 



0 Thursday 



Only between the following days of the month (inclusive): 

From: [oij “ To: [ff ~ 



Only between the following dates of the year (inclusive) 

E: 



From: January v 



To: 



December v 



E: 



Only between the following dates (inclusive): 



From: 2006 | | January vj 01 | * To: | 2007 [ ^ January vj 01 [ * 



OK 




Cancel 




Help 



1. In the Name field, enter a name for the object or leave to accept the default. 

2. Select Use Local Time Zone or Use UTC Time Zone. 

Local time sets the rule to follow the ProxySG internal clock. UTC sets the rule to use the 
Universal Coordinated Time (also known as Greenwich Mean Time or GMT). 

3. To specify a range for any given day, select Enable; in the Specify Time of Day Restriction (hh:mm) 
field, configure the times. The time style is military. 
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The range can be contained within one 24-hour calendar day, or overlap days. For example, 
configuring the time to range from 22:00 to 06:00 sets a limit from 10 at night to 6 the following 
morning. 

4. To specify a day of the week restriction, select Enable; in the Specific Weekday Restriction field, select 
one or more days. 

5. To specify a day of the month range restriction, select Enable; in the Specify Day of Month Restriction 
field, select the days, which are numbered from 01 to 31. To limit the range to specific day, 
configure the numbers to be the same. For example, selecting 22 and 22 specifies the rule to apply 
only the 22nd day of every month. 

6. To specify a restriction that spans one or more months, select Enable; in the Specify 
Annually-Recurring Date Restriction field, select the month and day ranges. This calendar restriction 
applies every year unless the restriction is altered. 

Overlapping months is allowed, similar to the behavior of day ranges in Step 3. 

7. To specify a one-time only restriction, select Enable; in the Specify Non-Recurring Date Restriction 
field, select the year, month, and day ranges. This calendar restriction applies only during the time 
specified and will not repeat. 

8. Click OK. 

Combined Time Object 

Allows you to combine a time object that adheres to multiple time restrictions. See "Using Combined 
Objects" on page 660. 

Time Column/Policy Layer Matrix 

The following matrix lists all of the Time column objects and indicates which policy layer they apply 
to. 



Object 


Admin 

Auth 


Admin 

Access 


DNS 

Access 


SOCKS 

Auth 


SSL 

Intercept 


SSL 

Access 


Web 

Auth 


Web 

Access 


Web 

Content 


Forwarding 


Time 






X 










X 






Combined Objects 






X 










X 
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Action Column Object Reference 

An action object determines which action to take if other parameters, such as source, destination, 
service, and time requirements validate the rule. 



Important: Because of character limitations required by the generated CPL, only alphanumeric, 
underscore, and dash characters can be used to define an action object name. 



Allow 

This is a static object. Selecting this overrides other related configurations and the specified user 
requests are allowed. 

Deny 

This is a static object. Selecting this overrides other related configurations and denies the specified 
user requests. 

Deny (Content Filter) 

This is a static object. Use this action when the intent of the rule is to enforce content-related policy so 
that Blue Coat Reporter can distinguish these actions from non content-related actions. The Deny 
(Content Filter) action results in a specific exception being written to the access log called 
"exception(content_filter_denied) . " 

Force Deny 

This is a static object. Forces a request to be denied, regardless if rules in subsequent layers would 
have allowed the request. 

Force Deny (Content Filter) 

This is a static object. Use this action when the intent of the rule is to enforce content-related policy so 
that Blue Coat Reporter can distinguish these actions from non content-related actions. The Force 
Deny (Content Filter) action results in a specific exception being written to the access log called 
"force_exception(content_filter_denied)." 

Allow Read-Only Access 

This is a static object. Grants full access to view data on the appliance. 

Allow Read-Write Access 

This is a static object. Grants full access to view and manipulate data on the appliance. 
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Do Not Authenticate 

This is a static object. Selecting this overrides other configurations and the specified users are not 
authenticated when requesting content. 

Authenticate 

Creates an authentication object to verify users. An authentication realm must exist on the ProxySG to 
be selected through VPM. 



Note: In the SOCKS Authentication policy layer, the object is SOCKS Authenticate. 



To create an Authenticate object: 




1. In the Name field, enter a name for the object or leave as is to accept the default. 

2. From the Realm drop-down list, select an authentication realm, which must already exist on the 
ProxySG. 

3. Optional (in the Web Authentication policy layer only): from the Mode drop-down list, select a 
mode. The mode determines the way the ProxySG interacts with the client for authentication 
specifying the challenge type and the accepted surrogate credential: 

• Auto — The default; the mode is automatically selected, based on the request. Selects among 

proxy, origin-IP, and origin-IP-redirect, depending on the type of connection (explicit or 
transparent) and the transparent authentication cookie settings. 
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• Form Cookie — For forms-based authentication: cookies are used as surrogate credentials. The 
cookies are set on the OCS domain only, and the user is presented with the form for each new 
domain. This mode is most useful in reverse proxy scenarios where there are a limited 
number of domains. 

• Form Cookie Redirect — The user is redirected to the authentication virtual URL before the form 
is presented. The authentication cookie is set on both the virtual URL and the OCS domain. 
The user is only challenged when the credential cache entry expires. 

• Form IP — The user's IP address is used as a surrogate credential. The form is presented 
whenever the user's credential cache entry expires. 

• Form IP Redirect — This is similar to Form IP except that the user is redirected to the 
authentication virtual URL before the form is presented. 

• Proxy — For explicit forward proxies: the ProxySG uses an explicit proxy challenge. No 
surrogate credentials are used. This is the typical mode for an authenticating explicit proxy. 

• Proxy IP — The ProxySG uses an explicit proxy challenge and the client's IP address as a 
surrogate credential. 

• Origin — The ProxySG acts like an OCS and issues OCS challenges. The authenticated 
connection serves as the surrogate credential. 

• Origin IP — The ProxySG acts like an OCS and issues OCS challenges. The client IP address is 
used as a surrogate credential. 

• Origin Cookie — For transparent proxies: for clients that understand cookies but do not 
understand redirects; the ProxySG acts like an origin server and issues origin server 
challenges. The surrogate credential is used. 

• Origin Cookie Redirect — For transparent forward proxies: the client is redirected to a virtual 
URL to be authenticated, and cookies are used as the surrogate credential. The ProxySG does 
not support origin-redirects with the CONNECT method. 

• Origin IP Redirect — Significantly reduces security; only useful for reverse proxy and when 
clients have unique IP addresses and do not understand cookies (or you cannot set a cookie). 
Provides partial control of transparently intercepted FITTPS requests. The client is redirected 
to a virtual URL to be authenticated, and the client IP address is used as a surrogate 
credential. The ProxySG does not support origin-redirects with the CONNECT method. 

• SG2 — The mode is selected automatically, based on the request using the SGOS 2.x-defined 
rules. 

4. (Optional) If you selected a Form mode in Step 3, the Authentication Form, New Pin Form, and Query 

Form drop-down lists becomes active. 

• Authentication Form — When forms-based authentication is in use, this property selects the form 
used to challenge the user. 

• New Pin Form — When forms-based authentication is in use, this selects the form to prompt 
user to enter a new PIN. 

• Query Form — When forms-based authentication is in use, this selects the form to display to the 
user when a yes/ no questions needs to be answered. 
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Note: The New Pin Form and the Query Form are only used with RSA SecurlD authentication. 



In most deployments, the default form settings should be adequate. However, if in your 
enterprise you have customized authentication forms configured (on the ProxySG Management 
Console: Configuration>Authentication>Forms), you can select them from the drop-down lists. For 
example, FIR_PIN. 

5. Click OK. 

Users are prompted to provide a valid user name and password. 

Force Authenticate 

Forces the user to authenticate even though the request is going to be denied for reasons that do not 
depend on authentication. This action is useful to identify a user before the denial so that the 
username is logged along with the denial. See "Authenticate" for a description of the fields in this 
object. 



Note: In the SOCKS Authentication policy layer, the object is Force SOCKS Authenticate. 



Bypass Cache 

This is a static object. Prevents the cache from being queried when serving a proxy request, and 
prevents the response from the origin server from being cached. 

Do Not Bypass Cache 

This is a static object. The ProxySG always checks if the destination is cached before going to the origin 
server; also, the content is cached if cacheable. 

Bypass DNS Cache 

This is a static object. Prevents the request from querying the DNS cache list of resolved lookup names 
or addresses. 

Do Not Bypass DNS Cache 

This is a static object. The ProxySG always queries the DNS cache list of resolved lookup names or 
addresses. 

Allow DNS From Upstream Server 

This is a static object. Allows the ProxySG to send requests for data not currently cached to DNS 
servers. 
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Serve DNS Only From Cache 

This is a static object. Instructs the ProxySG to only serve a DNS request from content that is already 
cached. 

Enable/Disable DNS Imputing 

These are static objects. If DNS imputing is enabled, the ProxySG appends the suffixes in the DNS 
imputing list to hostnames looked up when the original name is not found. 

Check/Do Not Check Authorization 

These are static objects. These actions control whether or not the ProxySG forces a request to be sent to 
an upstream server every time to check authorization, even if the content is already cached. The check 
action is not usually required for upstream origin content servers performing authentication, as the 
ProxySG automatically tracks whether content required authentication in each case. However, it can 
be required when an upstream proxy is performing proxy authentication because of the way some 
proxies cache credential information, causing them not to reliably challenge every request. When 
requests are directed to an upstream proxy which operates in this manner, enabling Check 
Authorization ensures that all such requests are properly authorized by the upstream proxy before the 
content is served from the local cache. 

Always Verify 

This is a static object. Cached content is always verified for freshness for the sources, destinations, or 
service specified in the rule. For example, the CEO and Executive Staff always require content to be 
the most recent, but everyone else can be served from the cache. 

Support/Do Not Support Persistent Client Requests 

These are static objects. Controls persistence of the connection to the HTTP client. 

Support /Do Not Support Persistent Server Requests 

These are static objects. Controls persistence of the connection to the HTTP server. 

Use Default Verification 

This is a static object. Overrides the Always Verify action and instructs the ProxySG to use its default 
freshness verification. 
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Block/Do Not Block PopUp Ads 

These are a static objects. Blocks or allows pop up windows. Blue Coat recommends creating separate 
Web Access policy layers that only contain pop up blocking actions. Furthermore, many Web 
applications require pop up windows. As it is unlikely that your Intranet contains pages that pop up 
unwanted advertising windows. Blue Coat recommends disabling pop up blocking for your Intranet. 
For example: 

□ Web Access rule 1: Specify the Intranet IP address and subnet mask in the Destination column and 
select Do Not Block Popup Ads in the Action column. 

□ Web Access rule 2: Select Block Popup Ads in the Action column. 

As you continue to modify policy, you can add more policy layers to block or allow specific IP 
addresses, but the policy layer as defined in the Web Access rule 2 above must always be positioned 
last. Blocking pop up ads is the default if a previous policy rule does not trigger. 

For more concept information about pop up windows, see "Section A: Blocking Pop Up Windows" on 
page 706. 

Force/Do Not Force IWA for Server Auth 

These are static objects. When configured for explicit proxy, Internet Explorer (IE) does not support an 
IWA challenge from an origin server. If Force IWA for Server Auth is applied, the ProxySG converts the 
401-type server authentication challenge to a 407-type proxy authentication challenge, which IE 
supports. The ProxySG also converts the resulting Proxy -Authentication headers in client requests to 
standard server authorization headers, which allows an origin server IWA authentication challenge to 
pass through when IE is explicitly proxied through the ProxySG. 

Reflect/Do Not Reflect IM Messages 

These are static objects. IM traffic can be contained and restricted to the network so that it never 
reaches the IM server. A hierarchy of ProxySG appliances manage the traffic and routes it depending 
on each ProxySG fail open and fail closed configurations. For detailed information about this 
deployment, see Chapter 17: "Instant Messaging" on page 769, of the Blue Coat ProxySG Configuration 
and Management Guide. 

Block/Do Not Block IM Encryption 

These are static objects. AOL IM provides the option for clients to send encrypted messages through 
both standard messaging (through the IM service) and direct connection messaging. These objects 
allow you to block or not block the ability to send encrypted messages through AOL IM. For detailed 
information about security benefits of this feature, see Chapter 17: "Instant Messaging" on page 769. 
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Require/Do Not Require Client Certificate 

These are static objects. For the SSL Proxy, specifies whether a client (typically a browser) certificate is 
required or not. 

□ In forward proxy deployments, this is used to either request consent certificates or to support 
certificate realm authentication. 

□ In reverse proxy deployments, client certificates are requested for certificate realm authentication. 
Also, see "Set Client Certificate Validation" on page 629. 

Deny 

This object provides the same functionality as the "Force Deny" object, but provides the option to 
re-allow authentication and insert substitution strings. 

Return Exception 

Allows you to select exception types and associate a custom message, if desired. Blue Coat provides a 
list of standard exceptions, but VPM also accepts user-defined values. 

To create a Return Exception object: 



1 ■ 
2a 

2b ' 

3 

4 

5 



>Name: 

® Built-in exception: 






Add Return Exception Object 



DNSException 



dns_server_failure 



User-defined exception: 

0 Force exception even if later policy would allow request 
□ Allow re-authentication 

•Details: 



Contact, your support department. 



OK 



Cancel 






Edit 



Help 



1. In the Name field, enter a name for the object or leave as is to accept the default. 

2. Perform one of the following: 
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a. Standard exception type: select one from the Built-in exception drop-down list. 

b. Custom exception (which already must be defined on the ProxySG) type: select one from 
the User-defined exception drop-down list. 

3. Optional: Select Force exception even if later policy would allow request to supersede other policy that 
applies to this request. 

4. Optional: Select Allow re-authentication to allow the user to re-enter credentials should the first 
attempt fail. 

5. Optional: in the Details field, enter a message that is displayed along with the summary and 
exception ID on the exception page displayed to the user when the exception is returned. 

The above example creates an object named DNSException2 that upon a DNS server failure returns a 
message to the user instructing them to contact their support person. 

To create custom exceptions, see "Defining Exceptions" on page 712. 

Return Redirect 

Aborts the current transaction and forces a client request to redirect to a specified URL. For example, 
used to redirect clients to a changed URL; or redirecting a request to a generic page stating the Internet 
access policy. Applies only to HTTP transactions. 



Note: Internet Explorer (IE) ignores redirect responses from FTP over HTTP requests, although 

Netscape Navigator obeys the redirect. To avoid problems with IE, do not use redirect 
when url . scheme=f tp. 



If the URL that you are redirecting the browser to also triggers a redirect response from your policy, 
then you can put the browser into an infinite loop. 

In the Name field, enter a name for the object (or leave as is to accept the default); in the URL field, 
enter the redirect destination URL. 



Example 

An object that redirects clients to an HTML policy statement page. 




Figure 14-17: Return Redirect Object 
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Set Client Certificate Validation 

If a client certificate is requested (see "Require/Do Not Require Client Certificate" on page 627), this 
object specifies whether the requested client certificate is validated. 

If Also check certificate revocation is selected, this is checked from a Certificate Authority. For 
information on using CRL, see "Checking CRLs" on page 236. 

Set Server Certificate Validation 

This feature is enabled by default. The SSL Proxy performs checks on server certificates. To mimic the 
overrides supported by browsers, the SSL Proxy can be configured to ignore failures for the first three 
checks in the list. 




If this feature is disabled, the 
features relating to enabled are 
greyed out. 



1. In the Name field, enter a name for the object or leave as is to accept the default. 

2. (Optional) Select one or more to ignore certain failures: 

• Ignore a hostname mismatch: Ignores the comparison of hostname in URL and certificate 
(intercepted connections only). 

• Ignore certificate expiration: Ignores the verification of certificate dates. 

• Ignore untrusted issuer: Ignores the verification of issuer signature. 

3. The certificate revocation list (CRL) option: 

If Also check certificate revocation is selected, this is checked from a Certificate Authority. For 
information on using CRL, see "Checking CRLs" on page 236. 
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Note: Two built-in exceptions can be used to notify the user that the verification of the server's 

certificate failed: exception . ssl_server_cert_expired and 
exception . ssl_server_unknown_ca. For information on using exceptions, see 
"Section D: Defining Exceptions" on page 712. 



Set SSL Forward Proxy 

The SSL Proxy enables the ProxySG to act as an HTTPS Forward Proxy, providing performance gains 
and security (authentication, content filtering, anti-virus scanning) for HTTPS traffic before it is 
delivered to clients. This object allows HTTPS content to be intercepted and examined. 

The default behavior is to Intercept as HTTPS only on exception, tunnel otherwise. 
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To create an SSL Forward Proxy Intercept object: 




1. In the Name field, enter a name for the object or leave as is to accept the default. 

2. Intercept as HTTPS: This option is selected by default. If you select Do not intercept, the fields for 
Intercept only on exception. Issuer Keyring, Hostname, Splash Text, and Splash URL are grayed out 
because they are not required. 

3. Intercept only on exception: This option is selected by default. When enabled the proxy intercepts as 
HTTPS only when an exception occurs. Server certificate errors and policy-based denials are some 
common exceptions. This setting is useful for providing a meaningful error message to end users. 

4. Issuer Keyring: Accept the default keyring or select this option and from the drop-down list select a 
previously generated keyring. This is the keyring used for signing emulated certificates. 

5. Hostname: The hostname you enter here is the hostname in the emulated certificate. 

6. Splash Text: The limit is 200 characters. The splash text is added to the emulated certificate as a 
certificate extension. The splash text is added to the emulated certificate as a certificate extension. 
For example: 

Visit http : / / corporate . com/https_policy . html 

To add substitution variables to the splash text, click Edit and select from the list. 

7. Splash URL: The splash text is added to the emulated certificate as a certificate extension. 



The SSL splash can be caused by such occurrences as when a browser receives a server certificate 
signed by an unknown CA, or a host miss-match. 
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Note: Not all browsers display the splash text and splash URL correctly. 



Send IM Alert 

Defines a message that is sent to an IM user by the ProxySG. The message is triggered by the IM 
parameters defined in the policy (for example, client login, sent or received messages, and buddy 
notification). Chapter 17: "Instant Messaging" on page 769 provides more information about 
regulating IM through the ProxySG, as well as VPM examples. 

Example 

A message that informs IM users their messaging is logged. 




Figure 14-18: Send IM Alert Object 

Modify Access Logging 

Defines access logging behavior. 

□ Disable all access logging — No activity is logged for the requests matched by the rule. 

□ Reset to default logging — Resets to logging the request to the default log specified by the ProxySG 
configuration, if one exists. 

□ Enable logging to — Enables logging of requests matched by this rule to the specified log. 

□ Disable logging to — Disables logging of requests matched by this rule to the specified log. 

Example: 

Enable logging P2P logging for this rule. 
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p Add Access Logging Object 



Name: AccessLogl 




O Disable all access logging: 



O Reset to default access logging 




Figure 14-19: Enabling access logging for peer to peer activity. 



Override Access Log Field 

Allows you to manipulate access log entries. For any specific log value, you can suppress the value, 
encode the value in Base64, or rewrite the value. 



To override Access Log fields: 



1 

2 

3 

4 




1. In the Name field, enter a name for the object or leave as is to accept the default. 

2. From the Log Name drop-down list, select a log (must already be configured on the ProxySG). 

3. From the Field Name drop-down list, select an access log field. 

4. Select one of the following: 

• Log original value — Records unmodified value in the access log. 
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• Suppress value — Prevents value from appearing in the access log. 

• Base64 encode value — Records an encoded version of the value in the access log. 

• Rewrite value — In the field, enter a string that replaces the value. Clicking Edit calls the Select 
The Rewrite String dialog. The substitution variables instruct the ProxySG to append specific 
information to the object. The variables are categorized alphabetically, according to prefix. 



Note: Some variables do not have prefixes, which allows you to substitute the value with 

information defined by other field types. 



5. Click OK. 

The above example creates an object called CEOLogRewrite that suppresses log entries so persons, such 
as support personal, cannot view economically sensitive information to gain improper knowledge. 

Rewrite Host 

Rewrites host component of a URL, specifying either Windows Media, Real Media, or all protocols. 
Use this to redirect the request to a different host. For example, rewrite www . traningl . com to 
www . training2 . com. You can create and name multiple rewrites, but you can only specify one per 
rule. 

To specify a rewrite: 



1 

2 

3 

4 



Add Rewrite Host Object 



Name: RewriteHostl 

Scheme: 

Pattern: 

Replacement : training2 



Windows Media v 
training 1 



Example: A pattern of "foo" with replacement"bar 
will transform "www.foo.com" into "www.bar.com". 



OK 




Cancel 




Help 



1. In the Name field, enter a name or leave as is to accept to the default. 

2. From the Scheme drop-down list, Windows Media, Real Media, or All to rewrite all URLs, regardless of 
protocol. 

3. In the Pattern field, enter a host name. 

4. In the Replacement field, enter the name the pattern is rewritten to. 

5. Click OK. 
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Reflect IP 

Specifies which IP address is used when making connections to upstream hosts. 
To create a Reflect IP object: 




1. In the Name field, enter name for the object or leave as is to accept the default. 

2. In the In outgoing client IP, reflect field, select one of the following: 

• Do not reflect IP — Disables reflecting IPs; the ProxySG uses the IP address of the interface that 
request is sent out on. 

• Incoming client IP [IP spoofing] — Reflects the client IP address. 

• Incoming proxy IP — Reflects the IP address of where the request arrived to. 

• Proxy IP — Specifies to reflect a specific IP of the ProxySG; enter the IP address in the field. 

• Use services configuration — Specifies whether to reflect IP in the configuration of the service 
which is used to process the request. 

3. Click OK. 

Example 

The above example reflects another IP address configured on the ProxySG. 
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Suppress Header 

Specifies one or more standard headers that are suppressed (not transmitted) on the outbound 
request, the outbound response, or both. 



To create a Suppress Header object: 




1. In the Name field, enter name for the object or leave as is to accept the default. 

2. Select Request, Response, or Both. The valid headers vary for requests and responses. Both displays 
a small subset of headers valid for requests and responses. 

3. Select one or more header types from the list. 

4. Click OK. 



The above example creates an object called EconomicConfidentialAccess to be used in a rule 
suppresses headers so specified users can access economically sensitive information without people, 
such as support personal, being able to gain knowledge of sources. 
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Control Request Header/Control Response Header 

Allows you to control and modify request or response headers by: 

□ Inserting a header with a specific value. 

□ Rewriting the value of a specific header. 

□ Suppressing a specific header. 

To create a Request Header or Control Response Header object: 




1. In the Name field, enter name for the object or leave as is to accept the default. 

2. From the Show drop-list select the viewing field from All to Standard or Custom, as desired. Standard 
displays only the default standard headers. Custom displays any admin-defined headers that exist. 

3. From the Header Name list, select a standard (pre-defined) header or a custom header if one has 
been defined. 

4. Select an action: 

• Suppress — The header is not visible. 

• Set value — Replace the header with a string or value. 

• Append to value — Add a string or value to the existing header. 

5. Click OK. 
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Notify User 

This action displays a notification page in the user's Web browser. A user must read the notification 
and click an Accept button before being allowed to access the Web content. You can customize the 
following: 

□ The page title, notification message, and the Accept button. 

□ The conditions that cause a notification to be displayed again. By default, the notification is 
displayed each time a user begins a new Web browsing session (reboots, logs out, or closes all 
Web browser windows). You can configure re-notification to occur for each new visited host or 
Web site, or after a time interval. 



Note: The Accept button click action is logged if HTTP access logging is enabled. A URL is 

logged that contains the string: accepted- Not if yName, where NotifyName is the 
name of the Notify User object. 



This feature is designed to provide the following functionality: 

□ Web-use compliance: A compliance page is a customized notification page displayed on a user's 
Web browser when attempting to access the Internet. This page ensures employees read and 
understand the company's Acceptable Use Policy before Internet use is granted. Typically, a 
compliance notification is displayed each time a browser is opened, but you can configure a time 
condition to display the page at specific intervals or times of the day, week, or month. 

□ Coach users: A coaching page displays when a user visits a Web site that is blocked by content 
filtering policy. This page explains why the site is blocked, the consequences of un-authorized 
access, and a link to the site if business purposes warrants access. A coaching page is configured 
to display each time a user visits a new Web page that is barred by content filtering policy; 
however, you can also configure this page to appear at different time intervals. 
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To configure HTML notification: 




1. In the Name field, enter a name for the object or leave as is to accept the default. 

2. In the Title field, enter a name that is the title of the page (text only; no HTML is allowed). 

3. In the Body field, compose a block of HTML that displays the message to the user. You can also 
customize the Accept link or button text. The HTML body must contain an Accept button or link. 
The default is: 

<bodyxa href ="$ (exception . details ) " onclick= "Accept ( ) ; " >Accept</ax/body> 



You can also use a button image (the image resides on an external Web server, as in the following 
example: 

cbodyxa href ="$ (exception . details ) " onclick= "Accept ();" > 

<img src="http : //server . com/images/accept . png" > </a> </body> 



If you use an HTML editor to compose code, you can paste it into the VPM; however, only copy 
the HTML from the <body> tag to the </body> tag. 

4. Under Notify mode, select an option that determines notification when visiting a new Web site: 
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• Notify once for all hosts — The notification page is displayed only once; this is used for 

configuring compliance pages. This option uses a Virtual Notify URL. If you must change the 
URL from the default value, please read the limitation section following this procedure. 



Note: This option might cause users to experience some noticeable Web browsing slowness. 



• Notify only once for related domains — The notify page reappears each time the user visits a new 
Web site; this is used for configuring coaching pages. 



Note: This option interferes with some Web advertising banners. In some cases, the 

notification page appears inside the banner. In other cases, banner ads are disabled by 
javascript errors. To fix these problems, do not serve notification pages for URLs that 
belong to the Web Advertising, Advertising, or Web Ads category. The actual name of 
this category varies with the content filtering vendor, and some vendors do not have 
an equivalent. 



• Notify on every host — The notify page reappears each time the user visits a new Web host. Blue 
Coat recommends that only highly experienced administrators employ this option. In 
addition to breaking banner ads, as described above in the previous option, this option, on 
some Internet Web sites, might cause Javascript errors that impair the functionality of the site. 

5. Under Notify users again, select an option that specifies when the notification expires and 

re-notification is required: 

• At next browser session — The notification page does not reappear until the next browser 
session. When a user reboots, logs out, or closes all Web browser windows, this ends the 
browser session. 

• After (time interval) — Notification reoccurs after the defined elapsed time (minutes or hours); 
this is useful for coaching. 

• After (specific time) — Notification reoccurs at a specific time of day. You can specify an interval 
of days; this is useful for compliance. 



Note: The time is referenced from the local workstation. If a compliance page is configured, 

verify the workstations and ProxySG clocks are synchronized. 



The above example creates a Notify Object with a custom message, set to display once a day after 7 
AM. 

Limitations and Workarounds 

If you must change the default Virtual Notify URL, consider the following: 

□ The Virtual Notify URL consists of an HTTP domain name or IP address (http : //); a port 
number is optional. 
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□ Do not use a host name that is explicitly defined as a trusted site on Internet Explorer 6 for 
Windows XP, Service Pack 2. Furthermore, only use domain names that contain dots. If you use 
domain names that do not contain dots, the HTTP redirects generated by the notification action 
causes Internet Explorer to display false warning messages each time the user is redirected from 
an untrusted site to a trusted site, or the other way around. 

□ For transparent proxy deployments, the domain name must be DNS-resolvable to an IP address 
that is in the range of destination IP addresses that are routed to the ProxySG. 

Policy Interactions 

This action generates CPL that might interfere with other policy or cause undesired behavior. 

Enhancements will occur in future SGOS releases. For this release, consider the following guidelines: 

□ Do not create VPM policy that modifies the Cookie request header. 

□ Do not create VPM policy that modifies the Set -Cookie and P3P response headers. 

□ Notification pages exist in the browser history. Therefore, if you click Accept and are taken to the 
requested page, then click the back button, you get the notification page again. 

□ If you have a chain of ProxySGs, with different notification pages configured on each appliance in 
the chain, then each notification page must have a different object name. 

Strip Active Content 

Strips HTTP tags from specified active content HTML pages. For each item you select for removal, 

you can also create a customized message that is displayed to the user. 



Note: Pages served over an HTTPS tunneled connection are encrypted, so the content cannot be 

modified. 



Chapter 15: "Section B: Stripping or Replacing Active Content” provides detailed information about 
the different types of active content. 
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To create a Strip Active Content object: 




3 



1. In the Name field, enter name for the object or leave as is to accept the default. 

2. Select the active content to be stripped. 

3. The default message in the Replacement Text column is Active Content Removed. To replace the 
default message, double click the field, enter a message, and press Enter. See the examples in the 
screenshot, Java applets have been removed. 

Exempting the ProxySG 

Stripping active content might interfere with Web applications deployed on your intranet. For 
example, if you create a policy rule that removes Java applets, and the destination defined in the rule 
contains an IP address of a ProxySG functioning as a proxy, the policy rule actually disables the 
Management Console because the Console itself is comprised of Java applets. 

To prevent this, for each ProxySG functioning as a proxy, create a rule that exempts the IP address of 
the ProxySG from the stripping action. 

1. Click Add Rule. 

2. Click Move Up; the rule to exempt the ProxySG must precede the rule that strips active content. 

3. In the Destination field, enter the ProxySG IP address. 

4. With the IP address entered, right-click it in the Destination field and select Negate from the 
drop-down list. 

5. In the Action field, enter the Remove Active Contents, Java Apps action. 
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File Edit Policy Configuration View Help 



Add Rule 


Delete Rule 


Move Up 


•4- Move Down 


Install Policy 


Web Access Layer (1) 




No. Source 


Destination 


Service Time Action 


Track Comment 


l|Any 


Destination: 10.1.1.1 |Any |Any 


jj19 JavaApps 


|None 



Figure 14-20: Exempting a Proxy SG IP Address 

HTTP Compression Level 

Allows you to set the level of compression to low, medium, or high. When configuring, consider that a 
higher compression level consumes more CPU resource. 



Note: If you enable HTTP Compression using the VPM but do not specify the HTTP 

Compression Level using VPM policy, then by default the level is Low. 



To specify an HTTP compression level: 

1. Select a compression level option: 

• Low — Equivalent to compression level 1. 

• Medium — Equivalent to compression level 6. 

• High — Equivalent to compression level 9. 

2. Click OK. 

The object is automatically named as Compression Level Low, Medium, or High. 

Set Client HTTP Compression 

Specifies the behavior when the client wants the content in a different compression form than is in the 
cache. 

To specify compression actions: 

1. In the Name field, enter name for the object or leave as is to accept the default. 

2. This object has two instructions: 

• A client requests compressed content, but only uncompressed content is available. Select to 
either compress the content before serving it, or serve uncompressed content. 

• A client requests uncompressed content, but only compressed content is available. Select to 
either uncompress the content before serving it, or serve compressed content. 

The default is to compress or decompress content, respectively, before serving it. 

3. Click OK. 
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For recommended compression configurations, see "Section B: Configuring HTTPS Reverse Proxy" 
on page 270. 

Set Server HTTP Compression 

Enables or disables HTTP compression. 

To specify compression options: 

1. In the Name field, enter name for the object or leave as is to accept the default. 

2. Select a compression option: 

• Disable HTTP compression — The default. Objects are not compressed. 

• Use client HTTP compression options — Default to the type of content requested by the client. 

• Always request HTTP compression — Force clients to always request compressed content. 

3. Click OK. 

For recommended compression configurations, see "Understanding HTTP Compression" on page 211. 

Set SOCKS Compression 

SOCKS compression reduces bandwidth and improves the latency between the main office, or core, 
and the edge proxies. This also applies to non- Web protocols (for example, Microsoft Exchange) that 
comprise large percentages of the enterprise traffic. 

For incoming SOCKS connections, this object determines if compression is allowed or not. This is 
typically used by a core (upstream) SOCKS proxy to allow SOCKS connections from an edge 
(downstream) SOCKS proxy. 

□ Allow compression — The gateway request to allow compression is granted. 

□ Do not allow compression — The gateway request to allow compression is not granted and the 
connection fails. 

For detailed information about SOCKS compression and policy, see "Understanding SOCKS 
Compression" on page 223. 

Set SOCKS Gateway Compression 

SOCKS compression reduces bandwidth and improves the latency between the main office, or core, 
and the edge proxies. This also applies to non- Web protocols (for example, Microsoft Exchange) that 
comprise large percentages of the enterprise traffic. 

This object determines whether a forwarded SOCKS connection requests compression or not. This is 
typically an edge (downstream) SOCKS proxy request to a core (upstream) SOCKS proxy. 



Note: The success of the compression request is determined by the upstream proxy, which can 

allow or deny a compression request. 
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□ Request compression — Asks the upstream proxy to allow a compressed SOCKS connection. 

□ Do not request compression — The request is forwarded, but compression is not required. 

□ Use gateway configuration setting — The request is forwarded, using the 

For detailed information about SOCKS compression and policy, see "Understanding SOCKS 
Compression" on page 223. 

Manage Bandwidth 

Allows you to manage bandwidth for all protocols or specific protocols, on both inbound and 
outbound traffic. 

To create a manage bandwidth object: 

1. In the Name field, enter name for the object or leave as is to accept the default. 

2. Select to limit bandwidth on the: Client side or Server side. 

• Client side — Traffic flowing between a client and the ProxySG. 

• Server side — Traffic flowing between a server and the ProxySG. 

3. Select to limit bandwidth for: Inbound or Outbound traffic. 

• Inbound — Network packets flowing into the ProxySG. Inbound traffic mainly consists of 
packets originating at the origin content server (OCS) and sent to the ProxySG to load a Web 
object and packets originating at the client and sent to the ProxySG for Web requests. 

• Outbound — Network packets flowing out of the ProxySG. Outbound traffic mainly consists of 
packets sent to the client in response to a Web request and packets sent to an OCS or other 
service (such as a virus scanner) to request a service. 

4. Select a Bandwidth Class from the drop-down list. 

5. Click OK; click Save Changes. 

For complete information about Bandwidth Management, see Chapter 10: "Bandwidth Management" 
on page 489. 

Modify IM Message 

In IM clients, replaces or appends the given text that is displayed to IM messages in clients that are 
logged in through the ProxySG. For example, use with Time Object to inform users that Instant 
Messages sent outside the corporate network are not allowed during business hours. 
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To create an IM message modification object: 




3 



1. In the Name field, enter a name for the object, or accept the default. 

2. In the text field, enter a message that appears on an IM client if the rule applies. 

3. Select one of the following: 

• Set message text — Replaces the text displayed to the IM client. See the example in the 
screenshot. 

• Append to message text — The specified text is added to the IM message. 

Chapter 17: "Instant Messaging" on page 769 provides more information about regulating IM through 
the ProxySG, as well as VPM examples. 

Return ICAP Patience Page 

Specifies to display an ICAP patience page after a predetermined amount of time. Enter a time value 
(in seconds) that the ProxySG waits for content to be serviced from the origin content server before 
displaying the page that instructs users an ICAP scan is in progress. 

Note: Patience pages display regardless of any pop up blocking policy that is in effect. 



Patience page management and limitations are described in "Customizing ICAP Patience Text" on 
page 520. 
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Set Dynamic Categorization 

Dynamic categorization extends the process of categorizing a URL. Traditional content filtering 
involves searching of massive URL pattern databases, which are published by vendors and 
downloaded to the ProxySG at specified intervals. As new content constantly reaches the Web, the 
limitation is that it cannot be filtered until its existence is discovered, added, and uploaded. Dynamic 
categorization enhances content filtering by scanning a new Web page, attempting to determine its 
contents, and categorizing accordingly in real time. 

When an un-categorized page is first encountered, the ProxySG calls an external service with a 
categorization request. Once the content is scanned, a category is assigned (a majority of the time). 

For related information, see "Configuring Dynamic Categorization for Blue Coat Web Filter" on 
page 800. 

To Configure Dynamic Categorization 

1. Select a mode: 

• Do not categorize dynamically — The loaded database is consulted for category information. 
URLs not in the database show up as category none. 

• Categorize dynamically in the background — Objects not categorized by the database are 
dynamically categorized as time permits. Proxy requests are not blocked while DRTR is 
consulted. Objects not found in the database appear as category pending, indicating that DRTR 
was requested, but the object was served before the DRTR response was available. 

• Categorize dynamically in realtime — The default. Objects not categorized by the database are 
dynamically categorized on first access. If this entails consulting the DRTR service, the proxy 
request is blocked until DRTR responds. 

• Use dynamic categorizing setting from configuration — Default to the ProxySG configuration 
(Content Filtering>Blue Coat>Dynamic Categorization). 

2. Click OK. 

Set External Filter Service 

Specifies which installed content filtering service or service group a content request is subjected to or 
bypasses, and specifies what occurs if a communication error occurs between the ProxySG and the 
external service. 
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To determine External Filter Service request behavior: 




To instruct all request 
types defined in the 
rule to not route 
through an external 
filter service for content 
filtering. 



1. In the Name field, enter a name for the object or leave as is to accept the default. 

2. To instruct all requests defined in the rule to route to a specific external filter service, select Use 
External Filter Service; from the drop-down list, select the external filter service or service group 
(which must already exist on the ProxySG; Configuration>External Services). 

3. In the Error handling field, select one of the following option: 

• To deny all requests if a communication error occurs, select Deny the client request. 

• To allow requests to go through without content filtering, select Continue without further external 
service processing. 

4. Click OK. 

Set ICAP Request Service 

Specifies which installed ICAP service or service group a content request routes to or bypasses, and 
specifies what occurs if a communication error occurs between the ProxySG and the ICAP server. 
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To determine iCAP request behavior: 




To instruct all request 
types defined in the 
rule to not route 
through an ICAP 
request service for AV 
scanning. 



1. In the Name field, enter a name for the object or leave as is to accept the default. 

2. To instruct all request or response types defined in the rule to route to a specific ICAP service, 
select Use ICAP Request Service; from the drop-down list, select the ICAP request modification 
service or service group (which must already exist on the ProxySG; Configuration>External 
Services>ICAP). 

3. In the Error handling field, select one of the following option: 

• To deny all requests or responses if a communication error occurs, select Deny the client request. 
This is the default and recommended by Blue Coat. 

• To allow requests or responses to go through without ICAP scanning, select Continue without 
further ICAP request processing. Be advised that this presents a content integrity risk. 



Note: When the ICAP service is restored, these objects are scanned and served from the 

cache if they are requested again. 



Set ICAP Response Service 

Identical to "Set ICAP Request Service", but applies to other protocol responses, such as HTTP and 
FTP. Requires an ICAP response modification service created on the ProxySG (Configuration>External 
Services>ICAP). 
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Set FTP Connection 

For an outgoing request over FTP, specifies whether the FTP connection should be made immediately 
or deferred, if possible. The benefit of deferring connections is that requests for previously cached 
content can be served without contacting the origin server, which reduces the FTP load on that server. 

Set SOCKS Acceleration 

Specifies whether or not accelerate SOCKS requests, and defines the transport method. 

To set SOCKS acceleration: 

1. In the Name field, enter a name for the object or leave as is to accept the default. 

2. Select one of the following: 

• Automatically — Accelerates SOCKS requests automatically, based on the destination port 
receiving the connection. 

• Do Not Accelerate — Never accelerate SOCKS requests matched by this rule. 

• Accelerate via [HTTP | AOL IM | MSN IM | Yahoo I M] — Specifies the type of acceleration applied 
to requests matched by this rule. 

3. Click OK. 

Set Streaming Max Bitrate 

Specifies the maximum bitrate, in kilobits per second, of requested streaming media. If a request 
exceeds this rule, the request is denied. 

Send DNS/RDNS Response Code 

Specifies to send out the default response code or a selectable error response code. Perform one of the 
following: 

□ Select Send Default DNS Response; optionally, enter a TTL (time to live) value. 

□ Select Send Error Response Code and select a code from the drop-down list. 

Send DNS Response 

Specifies which IP address to return for a specified host. 
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To set a DNS Response: 




4a 



4b 



1. In the Name field, enter a name for the object or leave as is to accept the default. 

2. In the Host field, enter a host name that is returned. 

3. To respond with the IP address of the proxy that is forwarding the request, select Respond with 
proxy IP. 

4. To respond with one or more IP addresses: 

a. Select Respond with listed IPs. 

b. Click Add. The Add DNS Response IP dialog appears. 

c. Enter an IP address and click Add. 

d. Repeat as required; click Close. 

5. (Optional) In the TTL field, enter a time-to-live value (how long the response is cached). 

6. Click OK. 

Send Reverse DNS Response 

Specifies which host to return for a reverse DNS response. Optional: define a time-to-live value. 
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Do Not Cache 

This is a static object. Specifies that objects are never cached. 

Force Cache 

This is a static object. Specifies that (cacheable) objects are always cached. Objects that are not 
cacheable (for example, RealMedia file types) and supported in pass-through mode only are not 
cached. 

Use Default Caching 

This is a static object. Overrides the Do Not Cache and Force Cache actions and instructs the ProxySG to 
use its default determination of whether or not to cache the content. 

Mark/Do Not Mark As Advertisement 

These are static objects. Specifies content to be identified as an advertisement. The ProxySG still 
fetches content from the cache (if present); however, just after serving to the client, the content is 
re-fetched from the ad server so that hit counters are updated. 

Enable/Disable Pipelining 

These are static objects. Enables or disables the ProxySG pipelining feature, which, when enabled, 
examines Web pages for embedded objects and requests them from the origin server in anticipation of 
a client request. 

Set TTL 

Specifies the time-to-live (TTL) an object is stored in the ProxySG. In the Name field, enter a name for 
the object (or leave as is to accept the default); in the TTL field, enter the amount of time in seconds. 

Send Direct 

This is a static object. Overrides forwarding host, SOCKS gateway, or ICP configurations and instructs 
the ProxySG to request the content directly from the origin server. 

Integrate/Do Not Integrate New Hosts 

This is a static object. Used in server accelerator deployments. When enabled, the corresponding host 
that is accessed is added to the list of hosts for which the ProxySG performs health checks. If that host 
name resolves to multiple IP addresses that correspond to different servers, the ProxySG fetches 
content from the available servers and ignores the servers that fail the health check. 
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Allow Content From Origin Server 

This is a static object. Allows request to access content from an origin server if the content is not 
cached. 

Serve Content Only From Cache 

This is a static object. Requests to access content that is not cached are denied. If the content is cached, 
the content is served. 

Select SOCKS Gateway 

Specifies which SOCKS gateway, if any, to use; defines behavior if communication between the 
SOCKS gateway and the ProxySG is down. 

□ To instruct the rule to connect directly without routing through a SOCKS service, select Do not use 
SOCKS gateway. 

□ To instruct the rule to connect through a SOCKS gateway, select Use SOCKS Gateway and select an 
installed SOCKS service from the drop-down list. 

In the If no SOCKS gateway is available field, select Deny the request or Connect directly, which allows 
requests to bypass the SOCKS service. 

Select Forwarding 

Specifies which forwarding host or group, if any, to use; defines behavior if communication between 
the forwarding and the ProxySG is down. 

□ To instruct the rule to connect directly without redirecting to a forwarding host or group, select Do 
not forward. 

□ To instruct the rule to redirect to a forwarding host, select Use Forwarding and select an installed 
forwarding host from the drop-down list. 

In the If no forwarding is available field, select Deny the request (fail closed) or Connect directly (fail open), 
which allows requests to bypass the forwarding host. 

□ To instruct the rule to forward using the ICP configuration, select Forward using ICP. 

Set IM Transport 

Specifies the transport method used for IM traffic. 

□ Auto — Connects using the transport method used by the client. 

□ FITTP — Tunnels the IM requests over HTTP. 

□ Native — Connects using the native transport used by the service. 
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Set Streaming Transport 

Specifies which streaming transport method the rule uses. 

□ Auto — Connects using the transport method used by the client. 

□ HTTP — Streaming over HTTP. 

□ TCP — Streaming over TCP. 

Authentication Charset 

The VPM allows you enter non- ASCII in many objects, such user and group names and text for the 
"Notify User” object. This object allows you set the character set to use in conjunction with localized 
policy. From the drop-down list, select a character set and click OK. 

Combined Action Objects 

Allows you to combine an action object that invokes multiple actions. See "Using Combined Objects" 
on page 660 . 

Action Column/Policy Layer Matrix 

The following matrix lists all of the Action column objects and indicates which policy layer they apply 
to. 



Object 


Admin 

Auth 


Admin 

Access 


DNS 

Access 


SOCKS 

Auth 


SSL 

Intercept 


SSL 

Access 


Web 

Auth 


Web 

Access 


Web 

Content 


Forwarding 


Allow 












X 




X 






Deny (static) 


X 


X 










X 


X 






Deny (Content Filter) 












X 




X 






Force Deny (Content Filter) 












X 




X 






Allow Read-Only Access 




X 


















Allow Read-Write Access 




X 


















Do Not Authenticate 


X 






X 






X 








Authenticate 


X 






X 






X 








Force Authenticate 


X 






X 






X 








Bypass Cache 
















X 






Do Not Bypass Cache 
















X 






Check Authorization 
















X 


X 




Do Not Check Authorization 
















X 


X 
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Object 


Admin 

Auth 


Admin 

Access 


DNS 

Access 


SOCKS 

Auth 


SSL 

Intercept 


SSL 

Access 


Web 

Auth 


Web 

Access 


Web 

Content 


Forwarding 


Always Verify 
















X 


X 




Use Default Verification 
















X 


X 




Block Up Ads 
















X 






Do Not Block PopUp Ads 
















X 






Force IWA For Server Auth 
















X 






Do Not Force IWA For Server 
Auth 
















X 






Require Client Certificate 












X 










Do Not Require Client 
Certificate 












X 










Reflect IM Messages 
















X 






Do Not Reflect IM Messages 
















X 






Support Persistent Client 
Requests 
















X 






Do Not Support Persistent 
Client Requests 
















X 






Support Persistent Server 
Requests 
















X 


X 




Do Not Support Persistent 
Server Requests 
















X 


X 




Block IM Encryption 
















X 






Do Not Block IM Encryption 
















X 






Deny 












X 




X 






Return Exception 












X 




X 






Return Redirect 
















X 






Set Client Certificate 
Validation 












X 










Set Server Certificate 
Validation 












X 










SSL Forward Proxy 










X 












Send IM Alert 
















X 






Modify Access Logging 
















X 


X 
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Object 


Admin 

Auth 


Admin 

Access 


DNS 

Access 


SOCKS 

Auth 


SSL 

Intercept 


SSL 

Access 


Web 

Auth 


Web 

Access 


Web 

Content 


Forwarding 


Override Access Log Field 
















X 


X 




Rewrite Host 
















X 






Reflect IP 






X 










X 






Suppress Header 
















X 






Control Request Header 
















X 






Control Response Header 
















X 






Notify User 
















X 






Strip Active Content 
















X 






Set Client HTTP Compression 
















X 






Set Server HTTP 
Compression 
















X 






Set SOCKS Compression 
















X 






Set SOCKS Gateway 
Compression 




















X 


Modify IM Message 
















X 






Return ICAP Patience Page 
















X 






Set Dynamic Categorization 


















X 




Set External Filter Service 
















X 






Set ICAP Request Service 
















X 


X 




Set ICAP Response Service 


















X 




Use Default Caching 


















X 




Set FTP Connection 
















X 






Set SOCKS Acceleration 
















X 






Set Streaming Max Bitrate 
















X 






Send DNS/RDNS Response 
Code 






X 
















Send DNS Response 






X 
















Send Reverse DNS Response 






X 
















Do Not Cache 


















X 




Force Cache 


















X 
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Object 


Admin 

Auth 


Admin 

Access 


DNS 

Access 


SOCKS 

Auth 


SSL 

Intercept 


SSL 

Access 


Web 

Auth 


Web 

Access 


Web 

Content 


Forwarding 


Mark As Advertisement 


















X 




Do Not Mark as 
Advertisement 


















X 




Enable Pipelining 


















X 




Disable Pipelining 


















X 




Set TTL 


















X 




Send Direct 




















X 


Integrate New Hosts 




















X 


Do Not Integrate New Hosts 




















X 


Allow Content From Origin 
Server 




















X 


Serve Content Only From 
Cache 




















X 


Select SOCKS Gateway 




















X 


Select Forwarding 




















X 


Reflect IP 




















X 


Set IM Transport 




















X 


Set Streaming Transport 




















X 


Authentication Charset 














X 








Combined Objects 






X 




X 


X 




X 


X 


X 



Track Object Column Reference 

A track object defines the parameters for tracking and tracing traffic. All policy layers contain the same 
trace objects, but tracking parameters are layer-specific. 



Note: Because of character limitations required by the generated CPL, only alphanumeric, 

underscore, and dash characters can be used to define an action object name. 
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Event Log, E-mail, and SNMP 

You can customize the event log. E-mail notification, and SNMP with triggers. These triggers are the 
same for all three object types. 

To customize an Event Log , E-mail, or SNMP Object: 

1. Right-click the Tracking cell in a policy layer and select Set; the Set Track Object dialog appears. 

2. Click New and select Event Log, Email, or SNMP; the appropriate add object dialog appears. 




5a 



5b 



5c 



3. In the Name field, enter a name for this object or leave as is to accept the default. 



Note: The e-mail object also contains a Subject field. 



4. In the Message Text field, enter a customized message that appears with each entry. 

5. Optional: Add substitution variables. The substitution variables instruct the ProxySG to append 
specific information to the tracking object. The variables are categorized alphabetically, according 
to prefix. 
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Note: Some variables do not have prefixes. 



In the Substitution Variables field: 

a. From the Category drop-down list, select a category to narrow the view to a subset of 
variables. 

b. The Display Option options allow you to further aggregate the variables by ELFF 
(Extended Log File Format) or CPL (Content Policy Language). 

c. Select a variable and click Insert. Rolling the mouse over a variable displays a brief 
description of the variable. Repeat as required. 

Tracing Objects 

This object specifies rule and Web traffic tracing. 

Click Trace Level and select one of the following trace options: 

□ No Tracing — The default. 

□ Request Tracing — Generates trace output for the current request. The trace output contains request 
parameters (such as URL and client address), the final values of property settings, and 
descriptions of all actions taken. 

□ Rule and Request — Generates trace output that displays each rule that was executed 

□ Verbose Tracing — Generates the same output as Rule and Request, but also lists which rules were 
skipped because one or more of their conditions were false, and displays the specific condition in 
the rule that was false. 

Furthermore, a trace destination can be entered that specifies the destination for any trace produced 
by the current transaction. To specify a destination path, select Trace File and enter a path in the field. 
For example, abc .html. 

If a trace destination is configured in multiple layers, the actual trace destination value displayed is 
the one specified in the last layer that had a rule evaluated (which has a destination property 
configured). Consider the following multiple Web Access Layer example, demonstrated by the 
generated CPL: 

< PROXY > 

url . domain=aol . com trace . request (yes) trace . rules (all ) 
trace . destination ( "aol_t racing . html " ) 

url . domain=msn. com trace . request (yes) 

trace .rules (all ) trace . destination ( "msn_t racing . html " ) 

< PROXY > 

client . address=10 . 10 . 10 . 1 trace . request (yes ) trace . rules (all) 

The resulting actions are: 

□ Requests to the aol . com domain are logged to aol_tracing . html. 

□ Requests to the msn . com domain are logged to msn_tracing . html. 
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□ Requests from the client with the IP of 10. 10. 10. 1 are logged to the default location of 
default . html. 



Note: After using a trace to troubleshoot, remove the trace to save log space. 



The Trace File option can be used in conjunction or separately from the Trace Level option. 

The default path of the trace file is accessible through one of the following URLs. 

If the Management Console secure mode is enabled (the default on a new or upgraded system): 
https : //Proxy SG_IP_address : 8082/Policy/Trace/def ault_trace . html 

If the Management Console is deployed in non-secure mode: 

http : / /Proxy SG_IP_address : 8081/Policy/Trace/def ault_trace . html 

Combined Track Object 

Allows you to combine track objects into one. See "Using Combined Objects". 

Track Objects/Policy Layer Matrix 

The following matrix lists all of the Track and column objects and indicates which policy layer they 
apply to. 



Object 


Admin 

Auth 


Admin 

Access 


DNS 

Access 


SOCKS 

Auth 


SSL 

Intercept 


SSL 

Access 


Web 

Auth 


Web 

Access 


Web 

Content 


Forwarding 


Event Log 




X 


X 




X 


X 




X 


X 




Email Log 




X 


X 




X 


X 




X 


X 




SNMP Objects 




X 


X 




X 


X 




X 


X 




Trace 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


Combined Objects 




X 


X 




X 


X 




X 


X 





Comment Object Reference 

The Comment object allows you to write any text to aid in labeling the policy layer. The text in this 
field does not impact the policy. 

Using Combined Objects 

As previously discussed, you select one object for as many object types as required for a given rule. 
Most object types also have the option of using a combined object. This feature allows you to select 
multiple objects for a given type, thus creating more complex tools. There are two uses for combined 
conditions: lists and multiple object types. Also consider the Negate option, which exempts the objects 
in the list. 
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Consider the following example. You want a Web Content policy layer that as an action forces 
authorization and sends the response to an ICAP service for content scanning. 




1. In the Set Action Object dialog, select New>Combined Action Object. 
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a Add Combined Action Object 



ji 



Hold Shift 
to select 
multiple 
objects. 



-OName: 

■O Description: 



Combined Action 1 



Authorize; scan request 



Show: All (sort by object-name) 



Selected Action Objects 



^ Always Verify 



r*j Branch_AV_Req 



EQ Branch_AV_Resp 



£ Branch_AV_Req 
Check Authorization 



jy[ Check Authorization 



Disable Pipelining 
Do Not Cache 
Do not Check Authorization 
m Do Not Mark as Advertisement 
I&32 Enable Pipelining 
if Force Cache 
fllTJ Mark as Advertisement 
£ Use Default Caching 
Q Use Default Verification 



Add >> 



Edit... 
Move Up 
Move Down 
Remove 



1 



New... 
% — 



Remove 



Edit... 



OK 



Cancel 



Click New to create new 
objects from this dialog. 



Help 



2. In the Name field, enter a name for this object or leave as is to accept the default. 

3. In the Description field, enter brief text that explains the intent of this object (for reference). 

4. The Show drop-down list allows you narrow the scope of the displayed objects. 

5. Hold the Shift key and select Check Authorization and Branch_AV_Req. 

6. Click Add. The selected objects appear in the Selected Action Objects field. 

7. Click OK. The CombinedActionl object appears as a separate, selectable object. 

8. Select CombinedActionl; click OK. The object is now part of the rule. 

Based on the other parameters specified in the rule, all requests are forced to an upstream server 
for authorization and the Web responses are subject to content scanning through the ICAP service. 
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Example Two 

In the following example, the rule searches for one of the Proxy IP Address/Port objects and one of the 
streaming client user agents. 




Figure 14-21 : A Combined Source Object with multiple object types. 

Note 

The VPM displays various warning messages if you attempt to add objects that creates an invalid 
combined object. However, it is possible to add a combined object to another combined object, even if 
doing so presents duplication of simple object definitions without receiving validation warnings. For 
example, the contents of a child combined object might have already been included either within the 
parent combined object directly, or indirectly within other child combined objects. This is allowable 
because of the complexity some combined objects and policies can achieve. 

Centralized Object Viewing and Managing 

This section describes how to use the All Objects dialog to view and manage every VPM object. 
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Viewing Objects 

The All Objects feature allows you view a list of all objects — both static and user-defined — that 
currently exist across all layers and columns. To view all configured VPM objects, in the Menu Bar 
select View>AII Objects. 




Figure 14-22: The All Objects dialog. 

The objects are displayed according to the policy layer order (click Policy in the menu bar) and the 
column order (as presented in "Policy Layer and Rule Object Reference" on page 579). To narrow the 
scope of the displayed objects, select from the Show drop-down list at the top: 

□ All (sort by object name): Displays all objects in alphabetical order. 

□ All (sort by object type): Groups object types together. 
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□ You can select to display only the static (predefined) objects for the Source, Destination, Service, and 
Action columns. 

□ You can select to display or any one object type. For example, you want to only view the 
user-defined P2P Client objects. Scroll down and select P2P Client Objects. 



All Objects 




Figure 14-23: Narrowing the list to User-Defined P2P objects. 

View Unused Objects 

Selecting Show only unused objects displays all static and user-defined objects that are not currently 
used in any policy layer. 

Managing Objects 

This section describes how to manage objects within the All Objects dialog. 

Creating Objects 

The All Objects dialog also allows you to create objects. Once an object is created, it appears in the list. 
When creating or editing policy layers, the objects are available to add to rules. 

To create an Object: 

1. Select New. The available columns and relevant objects are displayed in a cascade style. 

2. Select Column>Object. The Add dialog for that object appears. 

3. Define the object as required. 

4. Click OK. 
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Note: When creating Combined Objects, not all objects that appear in the left column are valid 

for more than one policy layer type. For example, the IM User object is only valid in the 
Web Access Layer>Source column. If you attempt to add an object that is not valid, a dialog 
appears with that information. 



Editing Objects 

Any user-defined object can be modified. Highlight the object and click Edit. After editing the object, 
re-install the policy to apply the modified object in every policy layer it exists in. 

Deleting Objects 

You cannot delete an object that is currently part of an installed policy or combined object. Before 
removing an object, you can use the View>Object Occurrences feature to identify which policy layers 
contain the object. 

Creating Categories 

This feature allows you create the content filter URL categories that can be used in the Category object. 
The Destination column in the DNS Access, Web Access, Web Authentication, and Web Content policy 
layers contain the Category object. Similarly, categories created in the Category object (see "Request 
URL Category" on page 605) appear in this dialog and can be edited. 

To create a Category: 

1. In VPM, select Configuration>Edit Categories. The Edit Categories dialog appears. 
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2. Select Policy; click Add. The Object Name dialog appears. 

3. Name the category and click OK. 
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4. Drop the Policy list and select the created category; click Edit URLs. The Edit Locally Defined 
Category Object dialog appears. 
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Add URLs to create 
a category of URLs. 



5. Enter URLs appropriate for the content filter category you are creating; click OK. 

6. Click OK in the Edit Categories dialog to complete the category creation. 



Note: If other administrators have access to the ProxySG through other workstations and are 

creating categories either through VPM or with inline commands, consider that 
newly-created or edited categories are not synchronized until the policy is installed. 
When the policy is installed with VPM, the categories are refreshed. If too many 
categories are created at the same time and confusion occurs, select the File>Revert to 
Existing Policy on ProxySG Appliance option to restore the policy to the previous state and 
reconfigure categories. 



Refreshing Policy 

In between occurrences when either VPM is closed and reopened or Install Policies is invoked, VPM 
does not recognize changes to VPM-managed policy that were made on the ProxySG through another 
method. For example: 

□ Another administrator opens a separate VPM to make changes. 

□ Another administrator edits the local or central policy file through the serial console. 
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□ Another administrator makes edits the local or central policy file through the Management 
Console. 

□ A new content filter database is downloaded automatically and the new update 
contains category changes. 

□ A new content filter database is downloaded manually by an administrator through the CLI or 
the Management Console. 

Restricting DNS Lookups 

This section discusses DNS lookup restrictions and describes how to create a list. 

About DNS Lookup Restriction 

The DNS lookup restriction list is a list of domain names that apply globally, regardless of policy layer 
definitions. Once a domain name is added to the list, DNS lookup requests do not occur for that 
domain name while policy is evaluated. For more detailed information about using DNS lookups, 
refer to the Blue Coat ProxySG Content Policy Language Guide. 

Creating the DNS Lookup Restriction List 

The list is created from the VPM Menu bar. 

To create the DNS Lookup Restriction List: 

1. Select Configuration>Set DNS Lookup Restrictions; the Set DNS lookup restrictions dialog appears. 
The default is None; no domain names are restricted. 

2. To restrict every domain name, select All. 

3. To add specific domain names, perform the following steps. 

a. Select Listed Host Patterns. 

This enables the Host Patterns field. 

b. Click Add; the Add Host Pattern dialog appears. 

c. Enter a domain name; click OK. 

d. Repeat to add other domain names. 

e. Click OK. 
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Restricting Reverse DNS Lookups 

This section discusses reverse DNS lookup restrictions and describes how to create a list. 

About Reverse DNS Lookup Restriction 

The Reverse DNS lookup restriction list is a list of subnets that apply globally, regardless of policy 
layer definitions. Once a subnet is added to the list, the ProxySG will not perform a reverse lookup of 
addresses on that subnet during policy evaluation. For more detailed information about using reverse 
DNS lookups, refer to the Blue Coat ProxySG Content Policy Language Guide. 

Creating the Reverse DNS Lookup Restriction List 

The list is created from the VPM Menu bar. This prevents the ProxySG from performing reverse DNS 
lookups of addresses in the list while evaluating policy. 

To create the Reverse DNS Lookup Restriction List: 

1. Select Configuration>Set Reverse DNS Lookup Restrictions; the Set Reverse DNS lookup restrictions 
dialog appears. 

The default is None; no subnets are restricted. 

2. To restrict every subnet, select All. 

3. To add specific subnets, perform the following steps. 

a. Select Listed Subnets. 

This enables the Subnets field. 

b. Click Add; the Add Subnet dialog appears. 

c. Enter a subnet; click OK. 

d. Repeat to add other subnets. 

e. Click OK. 

Setting the Group Log Order 

This section discusses the group log order and describes how to create a list. 

About the Group Log Order 

The Group Log Order object allows you to establish the order group data appears in the access logs. 
For more detailed information about using group log ordering, refer to the Blue Coat ProxySG Content 
Policy Language Guide. 
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Creating the Group Log Order List 

The list is created from the VPM Menu bar. 

To Create the Group Log Order List 

1. Select Configuration>Set Group Log Order; the Set Group Log Order dialog appears. 

2. Click Add; the Add Group Object dialog appears. 

3. In the Group Name field, enter the name of a group. 

The group must be already configured on the ProxySG. 

4. From the Authentication Realm drop-down list, select a realm. 

5. Click OK. 

6. Repeat as required to add more groups. 

7. To order the list, select a group and click Move Up or Move Down until you achieve the desired 
order. 

8. Click OK. 
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Section D: Managing Policy Layers, Rules, and Files 

This section contains the following topics: 

□ "How Policy Layers, Rules, and Files Interact" on page 673 — Describes the importance of rule 
order policy layer order. 

□ "Managing Policy" on page 676 — Describes how to save and install policies on the ProxySG. 

□ "Installing VPM-Created Policy Files" on page 678 — Describes how to propagate a policy file 
created on one ProxySG to another. 

□ "Viewing the Policy/ Created CPL" on page 681 — Describes how to view the underlying CPL that 
is created with VPM. 

How Policy Layers, Rules, and Files Interact 

The following critical points discuss the behaviors and priorities of policy rules, layers, and files: 

□ Rules in different policy layers of the same type work together, and the order of policy layers is 
important. 

□ The order of policy layers of different types is important. 

□ The order of rules in a policy layer is important. 

□ Policy created in VPM is saved in a file on the ProxySG; the state of the VPM user interface is also 
stored as an XML file on the ProxySG. 



Note: These files are stored only if the policy is installed without any errors. 



□ How the appliance evaluates those rules in relation to policy layers that exist in the central and 
local policy files is important. For more information, see Chapter 13: "Managing Policy Files" on 
page 553. 

How VPM Layers Relate to CPL Layers 

VPM generates CPL in various layers, but the concept of layers presented in VPM is slightly different. 
VPM provides policy layers for special purposes. For example, Web Authentication and Web 
Authorization, which both generate CPL < Proxy > layers. This minimizes timing conflicts by 
restricting the choices of triggers and properties to those compatible timing requirements. The 
following table summarizes how to use VPM layers and which CPL layers result. 
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Table 14.2: VPM-Generated CPL Layers 



Policy Purpose 


VPM Layer 


CPL Layer 


Establish Administrator identities. 


Admin Authentication 


<Admin> 


Control Administrator access. 


Admin Authorization 


<Admin> 


Control DNS access. 


DNS Access 


<DNS> 


Establish SOCKS user identities. 


SOCKS Authentication 


< Proxy > 


Allow HTTPS interception. 


SSL Intercept 


<SSL- Intercept > 


Control HTTPS traffic. 


SSL Access 


<SSL> 


Establish user identities. 


Web Authentication 


< Proxy > 


Control user access. 


Web Access 


< Proxy > 


Control content independent of users. 


Web Content 


<Cache> 


Control forwarding. 


Forwarding 


<Forward> 



Note: VPM currently does not support the <Exception> layer. 



Ordering Rules in a Policy Layer 

The ProxySG evaluates the rules in the order in which they are listed in a policy layer. When it finds a 
rule that applies to the situation, it skips the remaining rules in the policy layer and goes on to the next 
policy layer. 

Consider the following simple example. Assume that a company has a policy that prohibits everyone 
from accessing the Web. This is a policy that is easy to create with a Web Access layer rule. 

There are, however, likely to be exceptions to such a broad policy. For example, you require the 
manager of the purchasing department to be able to access the Web sites of suppliers. Members of the 
sales department need to access their customer Web sites. Creating Web Access rules for both these 
situations is also simple. But if you put all these rules in a single policy layer, then the rule prohibiting 
access to everyone must be ordered last, or the other two rules are not applied. 

Principle Design Rule: 

Always go from the specific to the general. 

Using Policy Layers of the Same Type 

Because the ProxySG skips the remaining rules in a policy layer as soon as it finds one that meets the 
condition, multiple policy layers and a combination of rules might be required to accomplish a task. 
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Consider the following example. A company does not want to prohibit its employees from accessing 
the Web, but it does not want them to abuse the privilege. To this end, the company wants employees 
who access the Web to authenticate when they do so; that is, enter a username and password. So the 
company creates a Web Authentication policy layer with a rule that says: "If anyone from anywhere in 
the company sends a request to a URL on the Web, authenticate the client before granting access." 

The company also allows members of the group Sales to access various sports Web sites only during 
non-work hours. Given the Web Authentication rule above, these people must authenticate when they 
do this. But the company feels that it is not important for people going to these sites after hours to 
authenticate. So the company creates the following Web Access policy-layer rule: 

□ Grant Sales personnel access to sports Web sites from 5:00 PM to midnight. 

But there are additional issues. Some members of the sales department spend a lot of time 
watching game highlights on video clips, and this takes up a lot of bandwidth. At the same time, a 
lot of customers access the company Web site in the evening (during non-work hours), so internal 
bandwidth should remain manageable. The company, therefore, limits the bandwidth available to 
the people in the Sales department with a Web Access layer rule that is identical to the one above 
in all respects except for the action: 

□ Grant Sales personnel access to sports Web sites from 5:00 PM to midnight, but limit the 
maximum streaming bitrate to 300 kilobits per second. 

For both these rules to work, they need to be in separate policy layers. If they were in the same policy 
layer, the rule listed second would never be applied. 

Ordering Policy Layers 

The order of policy layers is also important. The ProxySG evaluates policy layers in the order in which 
they are listed in VPM. When the ProxySG is going through policy layers, it does not execute a given 
rule as soon as it finds that it meets the specific situation. Rather, it compiles a list of all the rules that 
meet the condition; when it has gone through all the policy layers, it evaluates the list, resolves any 
apparent conflicts, and then executes the required actions. If there is a conflict between rules in 
different policy layers, the matching rule in the policy layer evaluated last takes precedence. 

In the above example, there are two Web Access policy layers: one contains a rule stating that Sales 
personnel can access certain Web sites without authenticating, and the other states that when they do 
access these Web sites, limit the available bandwidth. The order of these policy layers is irrelevant. The 
order is irrelevant because there is no conflict between the rules in the layers. 

The following is an example in which the order of policy layers does matter. Assume all URL requests 
from members of the purchasing department are directed to a single proxy server. To discourage 
employees from surfing the Web excessively during business hours, a company creates a Web 
Authentication Policy rule that says: "Whenever a client request comes in to the proxy server, prompt 
the client to authenticate." 

Members of the purchasing department, however, need to access specific Web sites for business 
reasons, and the company does not want to require authentication every time they do this. So they 
create a Web Access policy rule that says: "If any member of the purchasing department sends a 
request to a specific URL contained in a combined-object list, allow access." 
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The policy layer with the first rule needs to come first in evaluation order; it is then overridden by the 
second rule in a subsequent policy layer. 

Principle Policy Layer Design Rule 

Always go from the general to the specific; that is, establish a general rule in an early policy layer, then 
write exception rules in later policy layers. 

Installing Policies 

As you add policy layers and rules, your work is saved in a file on the ProxySG. However, policies 
only take effect after you install the policies and the generated XML has been validated. The ProxySG 
then compiles the policies into CPL format and saves the resulting policies in the vpm. cpl file. This 
overwrites any policies previously created using VPM. The appliance saves VPM-generated policies 
in a single file and loads it all at once. You do not need to load policies separately, as is the case with 
the local or central policy files. 

To Install Policies 

□ Select File>lnstall Policies, or 

□ Click Install Policies on the Rule bar. 

The VPM validates the generated XML for any issues, such as missing layers. If the validation 
passes, the CPL is generated and the policies are loaded. 

If the XML fails the validation, a dialog appears allowing you to: 

• Revert to the policy currently installed on the ProxySG, or 

• Continue to edit the policy and attempt another installation. 

Furthermore, the failed XML file is written to your hard disk; view this file to troubleshoot the 
failed XML. The default location for this file is: 

C:\Documents and Settings\user.name\bluecoat\vprn_err.xml 



Notes 

The Category and Notify User objects and the DNS Lookup Restrictions, Reverse DNS Lookup Restrictions, 
and Group Log Order configuration objects generate CPL, regardless if they are or are not included in 
rules. These specific objects and features allow users to edit categories and lists that might or might 
not be used in current policies. 

Managing Policy 

This section describes how to manage VPM policy. 

Refreshing Policy 

In between occurrences when either VPM is closed and reopened or Install Policies is invoked, VPM 
does not recognize changes to VPM-managed policy that were made on the ProxySG through another 
method. For example: 
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□ Another administrator opens a separate VPM to make changes. 

□ Another administrator edits the local or central policy file through the serial console. 

□ Another administrator makes edits the local or central policy file through the Management 
Console. 

□ A new content filter database is downloaded automatically and the new update 
contains category changes. 

□ A new content filter database is downloaded manually by an administrator through the CLI or 
the Management Console. 

Reverting to a Previous Policy 

If after creating new policies or editing an existing policy you decide to abandon the process and 
continue with the existing policy installed on the ProxySG, you can revert to that version. All current 
changes are deleted (VPM provides a verification prompt). 

To Revert to an Existing Installed Policy 

Select File>Revert to Existing Policy on ProxySG Appliance. 

Changing Policies 

You can change, edit, delete, add to, and otherwise manage policies created in VPM at any time by 
returning to VPM and working with policy layers and rules just as you did when creating them. 

Managing Policy Layers 

This section describes how to perform edits of policy layers. 

Renaming a Policy Layer 

The VPM allows you to rename policy layers and disable and re-enable layers. 

To rename a Policy Layer: 

1. Right-click the tab of the policy layer and select Rename. The Rename New Layer dialog appears. 

2. Rename the layer and click OK. 

Disabling a Policy Layer 

Disabling policy layers allows you to remove a subset of the employed policy without losing the rules 
and the effort put forth to create them. Once disabled, the policy in that layers is ignored. You can 
re-enable a disabled layer at any time. 

To disable or Enable a Layer: 

Right-click the tab of the policy layer and select Disable Layer. The layer name text turns red and the 
layer rules are greyed-out. 
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To re-enable a layer, repeat this step and select Enable Layer. 

Deleting a Policy Layer 

You can completely remove a policy layer. 



Important: Once deleted, a layer cannot be recovered. 



To Delete a Policy Layer 

1. Right-click the tab of the policy layer to be deleted. 

2. Select Delete Policy from the drop-down list. 

Note: All of the above procedures can be accomplished from the Menu Bar>Edit drop-down list. 



Managing Policy Rules 

Occasionally, you might need to temporarily disable rules in a policy layer; for example, when 
troubleshooting compiles errors and warnings. This might help confirm that the ProxySG can 
successfully compile the remaining policy. After disabling a rule, you can edit the objects and 
re-enable the rule. 

To disable or enable a rule: 

1. Click the appropriate policy layer tab. 

2. Right-click in the No. column. 

3. Click Disable Rule on the shortcut menu. The policy editor changes the rule text color to red. 

4. To enable the rule, repeat step 3. After you enable a disabled rule, the policy editor changes the 
rule text color to black. 

Installing VPM-Created Policy Files 

Policies created with VPM are saved on the specific ProxySG on which they are created. SGOS 
automatically creates the following files when saving VPM-created policies: 

conf ig_policy_source .xml 
conf ig_policy_source . txt 

You can install VPM policies that were created on another ProxySG. This requires the following steps: 

1. Copy the two VPM files, to be shared, to a Web server from the ProxySG on which they reside. 

2. Use the Management Console or CLI to load VPM files on another ProxySG. 
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To copy VPM files from a ProxySG to a Web server: 

1. Select Statistics>Advanced. 

2. Scroll down and click Policy. 

The page jumps down to the Policy files links. 



Policy 

• List of policy URLs 

• Show policy statistics 

• Reset policy statistics 

• Show current policy 

• Delete all policy traces 

• Results of policy load 

• Show central policy 

• Show forward policy 

• Show local poiicv 

• Show VPM CPL policy 

• Show VPM XML policy 



Figure 14-24: Policy Files in Custom URLs 

3. Right-click the Show VPM CPL policy link. 

4. In the Save As dialog, enter the full path to a directory on the Web server before the file name and 
click OK. 



Important: The Save As dialog offers the appropriate default file name 

(conf ig_policy_source . xml or conf ig_policy_source . txt) . You can 
change the names, including the extension. This can be helpful if an enterprise 
is using various sets of shared VPM files. You could rename files to indicate the 
ProxySG on which they were created, for example, or for a department that has 
a set of VPM-specific policies, used perhaps in multiple locations (sales_vpm.cpl 
and sales_vpm.xml). 



5. Repeat the previous step for the second VPM file. 

To load VPM files to a ProxySG through the Management Console: 
1. Select Conifiguration>Policy>Policy Files>Visual Policy Files. 
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2. In the Install Visual Policy field: 

a. Select Remote URL from the Install VPM-CPL from drop-down list. 

b. Click Install. The Install VPM-CPL dialog appears. 



Install VPM-CPL 






r Install VPM-CPL 

Installation URL: [ https://server.example.com/IT/policy.txt 



Install I View 




r Installation Status 



OK | | Cancel | 



Java Applet Window 

c. In the Installation URL field, enter the URL to the VPM CPL file copied to the Web server 
(this is the file with the default . txt extension) and click Install. 

d. Repeat Steps a through c to enter the URL to the second VPM XML file copied to the Web 
server (this is the file with the default .xml extension) and click Install. 

3. Click Apply. 
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□ If VPM files already exist on the ProxySG, the URLs to those files display in the two file fields. To 
replace them, delete the URLs and type new ones. Installing new files overwrites any that are 
already present. 

□ To review VPM-generated policies before installing them, enter the URL to the CPL file on the 
Web server and click View. 

□ Regardless of whether you are installing new VPM files, you can review the CPL or XML files of 
the policies currently on the ProxySG. Click VPM-CPL and VPM-XML in the View Visual Policy Files 
box at the bottom of the dialog. 

□ Never edit either of the VPM files directly. Change the files only by working with the policies in 
VPM and saving changes there. 

To Load VPM Files to a ProxySG through the CLI 

The two commands in the first step load one of the VPM policy files; the commands in the second step 
load the other policy file. In each case, url is the complete path, including file name, to the 
appropriate file on the Web server. 

1. At the conf ig command prompt, enter the following commands: 

SGOS# (config) policy vpm-cpl -path url 
SGOS# (config) load policy vpm-cpl 

2. At the config command prompt, enter the following commands: 

SGOS# (config) policy vpm-xml -path url 
SGOS# (config) load policy vpm-xml 

Viewing the Policy/Created CPL 

View the CPL generated by installing VPM-created policy from VPM or the Management Console. 

To View the Generated CPL through VPM 
Select View>Generated CPL. 

To View the VPM Policy File 

Select View>Current ProxySG Appliance VPM Policy Files. 



Important: Do not edit or alter VPM-generated files by opening the VPM policy file and 

working in the generated CPL. To edit, change, or add to VPM policies, edit the 
policy layers and re-install the policy. 
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Section E: Tutorials 

This section contains the following topics: 

□ "Tutorial — Creating a Web Authentication Policy" on page 683 

□ "Tutorial — Creating a Web Access Policy" on page 691 
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Tutorial — Creating a Web Authentication Policy 

This section is a tutorial that demonstrates how to create policies and rules for Web authentication. 

Use Web Authentication policies to specify whether the individual making a request is prompted to 
authenticate by entering a username and password. In this example, a company uses a PAC file to 
configure most employee browsers to connect to a specific IP address on the ProxySG. It wants these 
users to authenticate when their browsers send a request to the proxy. 



To create a policy layer: 

1. Start the VPM from the Management Console: Configuration>Policy>Visual Policy Manager. 







File Edit 1 




Web Acces 


No. 









Configuration View Help 



Add Admin Authentication Layer... 
Add Admin Access Layer. . . 



Add SSL Access Layer. . 



Add Web Authentication Layer. . 



* Add Web Access Layer. . . 
Add Web Content Layer. . 
Add Forwarding Layer. . . 



' t ' Move Up ^ Move Down ^ Install Policy 



Add SOCKS Authentication Layer. . . 


Time 


Action 


Track 


Comment 


Add SSL Intercept Layer. . . 


|Any 


\Q Deny 


None 





2. Select Policy>Add Web Authentication Layer. 




3. A dialog displays offering a default name for the layer, consisting of the layer type and a number. 
Rename the layer or accept the default and click OK. 

The VPM creates the new layer tab and adds a blank rule. 

Example 1 : Create an Authentication Rule 

By default, the unmodified rule applies to everyone whose browsers connect to a specific IP address. 



683 





Blue Coat ProxySG Configuration and Management Guide 



Section E: Tutorials 



Web Access Layer (1) Web Authentication Layer (1) j 

No. Source Destination Action Track Comment 




Delete 

Negate 

Cut 

Copy 

Paste 




1. Right-click the Source cell to drop the menu; select Set to open the Set Source Object dialog. 

2. Select a proxy IP address or port; if necessary, click New to create a new one. This example selects 
the IP address on the ProxySG where the PAC file sends most employee browsers. 



3. Click OK to enter the IP address in the Source cell. 
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Web Access Layer (1) Web Authentication Layer (1) 1 


No. Source Destination Action Track Comment 


lj^ 10.1.1.1:80 [Any 


1 




Edl^^ 

Delete 






4. Create an authentication Action object. Right-click the Action cell to drop the menu and select Set; 
the Set Action Object dialog displays. 

5. The only objects available are the pre-existing static objects, so you must create a new 
Authenticate object. Click New and select Authenticate. The Add Authenticate Object window 
displays. 
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6. For this example, the following fields are: 

• Name — Every configurable object has a name. The default name Authenticate 1 ; change to 
Authenticate_Example_Corp, which is how it is listed in the Add Object window. 

• Realm — Specifies an LDAP realm. 

• Mode — Specifies the authentication realm mode is Origin IR 

7. Click OK to close the Add Action Object window, with the new Authenticate object in the list. 




8. Click OK. 
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Figure 14-25: Completed Action Object 

9. Create a Trace object to log all authentication activity. Right-click the Track cell to drop the menu 
and select Set; the Set Track Object dialog appears. 

10. You must create a new Trace object. Click New and select Trace; the Add Trace Object appears. 




11 



12 



11. In the Name field, enter AuthTrace. 

12. Click Trace Level and Verbose to enable verbose tracing, which lists the rules that were skipped 
because one or more of their conditions were false and displays the specific condition in the rule 
that was false. 

13. Click OK. 

14. Click OK again to add the object. The rule is complete. 



File Edit Policy Configuration View Help 


Add Rule 


"p Delete Rule 


-f- Move Up 


Move Down 


Install Policy 




Web Access Layer (1) 


Web Authentication Layer (1) 








No. Source 


Destination 


Action 


Track 


Comment 




lUny 
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W5 Authenticate. 


_Ex... l£) AuthTrace 


i 


::: 





Figure 14-26: Completed Rule 
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Example 2: Exempt Specific Users from Authentication 

Certain individuals and groups are exempt from the above restriction. Individuals in the purchasing 
department are required to access the Web often so they can order online from supplier Web sites, and 
the company does not want them to authenticate. 



File Edit Policy Configuration View Help 


*ri Add Rule 
l\ 


™p Delete Rule 


•f- Move Up 


4- Move Down 


Install Policy 




| ‘ , . 1 , Authentication Layer (1) 

Add rule to selected policy 






No. Source 


Destination 


Action 


Track 


Comment 


1 Any 


|Any 


Authenticate_Ex... AuthTrace 


I 


2 Any 


Any 


None 


None 


■ 



1. Click Add Rule to add a new rule to this policy layer. 



File Edit Policy Configuration View Help 


*p Add Rule ™p Delete Rule 


^ Move Up 


•4- Move Down 


^ Install Policy 




Web Access Layer (1) Web Authentication Layer (1) | 








No. Source Destination 


Action 


Track 


Comment 






2. People in the purchasing group use the same PAC file and thus their browsers are directed to the 
same IP address: 10.1.1.1. 



Set Source Object 



Any 
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File Edit Policy Configuration View Help 


*p Add Rule 


™p Delete Rule 


f - Move Up 


Move Down 


^ Install Policy 




Web Access Layer (1) 


Web Authentication Layer (1) | 








No. Source 


Destination 


Action 


Track 


Comment 




1 & Client: 10.1.1.1 |Any 




^HNone 













3. Change the Action object to Do Not Authenticate and click OK. 

The new rule in the policy layer accepts the default Action Object to not authenticate and does not 
require a Trace Object. 



File Edit Policy Configuration View Help 



Add Rule 



™p Delete Rule 


•f- Move Up 


4- Move Down 


Install Policy 



Web Access Layer (1) | Web Authentication Layer (1) 



No. 


Source 


Destination 


Action 


Track 


Comment 


1 


Any 


Any 


Authenticate_Ex... 


Auth_Trace 


2 


gradient: 10.1.1.1 


Any 


£ Do Not Authenti. . . 


None 



Figure 14-27: Updated Second Rule 



However, a problem exists. The second rule cannot be evaluated because the first rule affects 
everyone who goes through the proxy. The rules need to be reversed. 
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File Edit Policy Configuration View Help 


*p Add Rule 


™p Delete Rule 


-f- Move Up 


4- Move Down 


Install Policy 




Web Access Layer (1) Web Authentication Layer (1) ^ 




No. Source 


Destination Action Track 


Comment 


1 


Client: 10.1.1.1 


Any 


£) Do Not Authentic . 


None 




2 


Any 


Any 


f-fy Authenticate_Ex... 


£) Auth_Trace 





4. Select the second rule and click Move Up to reorder the rules. 
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Tutorial — Creating a Web Access Policy 

This section is a tutorial that demonstrates how to create policies and rules for Web access. 

Use ProxySG policies to define end-user access to Web resources. For more information about Web 
access policies, see Chapter 18: "Content Filtering" on page 785. This section provides examples. 

Example 1 : Restrict Access to Specific Web Sites 

This example demonstrates a simple rule that denies everyone access to specific job searching Web 
sites. This rule requires you to configure only one rule option; it uses the defaults for all other options. 

1. Start the policy editor and select Policy>Add Web Access Layer. The VPM displays a tab with the 
name of the new policy; beneath that is a new rule-specific row. 




2. Right-click Destination and select Set; the Set Destination Object dialog appears. 
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3. Click New; select Combined Destination Object. The Add Combined Destination Object dialog 
appears. 
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4. Select New>Request URL. 
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8 



5. Click Simple Match; in the URL field, enter hotjobs.com. 

6. Click Add. 

7. Repeat step 5, adding monster.com and bajobs.com. 

8. Click Close. 
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9. Select each newly added URL and click the first Add button. 

10. Click OK. The Set Destination Object now contains the individual URL objects and the combined 
object. 

11. Select the JobSearchURLs combined object and click OK. The object is now part of the rule. 




Figure 14-28: Completed Rule 

As the default action is deny, the rule is complete. No one can access these Web sites. 

12. To activate the rule, click Install Policies. 

Example 2: Allow Specific Users to Access Specific Websites 

The after-hours IT shift is comprised of part-time college interns who are on call to handle small 
problems, but are not involved in major projects. Therefore, you allow them to browse certain sports 
and entertainment Web sites when all is quiet; access is allowed from two workstations and you still 
want to track their browsing activity. 
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To configure the Source Object: 



File Edit Policy Configuration View Help 



-O *p Add Rule 



Delete Rule 
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^ Install Policy 



Web Access Layer (1) Web Authentication Layer (1) 

No. Source Destination Service 
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Time 
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Action 
Q Deny 
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Track 
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Comment 



£ Set Source Object 
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Show: 



Q Deny Nc 
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All (sort by object-name) 



Authenticated User 



a? Client Hostname Unavailable 
Streaming Client 




New.. 



Remove 



Edit.. 



Client IP Address/Subnet. . . 

Client Hostname... 

Proxy IP Address/Port. . . 

User... 

Group... 

Attribute... 

User Agent... 

IM User Agent... 

Request Header... 

SOCKS Version... 

IM User... 

P2P Client... 

Client Negotiated Cipher Strength. . . 



• Combined Source Object.. 






Help 




1. Add a new rule to the policy and position the pointer in the Source cell. 

2. Right-click the Source cell and select Set to display the Add Source Object dialog. 

3. Click New and select Combined Source Object; the Add Combined Source Object appears. 
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4 



5 



4. Name the object IT_PM_Shift. 

5. Under the selectable list of objects, click New and select Client IP Address/Subnet; the Add Client IP 
Address/Subnet Object dialog appears. 




6. Enter the IP address of the first workstation and click Add; repeat for the second; click Close. 
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7. Select each IP address and click the first Add. 

8. Click OK; click OK again to add the Source object to the rule. 
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To configure the Destination Object: 



File Edit Policy Configuration View Help 



Add Rule 


"q Delete Rule 
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Install Policy 
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Q Deny 
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£ Set Destination Object 






■Existing Destination Objects - 
Show: 



All (sort by object-name) 



^ Popular JobSearchURLs 
^ Request URL: bajobs.com 
3 Request URL: hotjobs.com 



Request URL: monster. c 



New.. 



Edit.. 



Destination IP Address/Subnet... 
Destination Host/Port. . . 

Request URL... 



Request URL Category. . . 



Help 



l^File Extensions... 
HTTP MIME Types... 



1. Right-click the Destination field and select Set; the Set Destination Object dialog appears. 

2. Click New and select Request URL Category; the Add Request Category Object dialog appears. 
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4 



3. Select Policy and click Add; the Enter Name for New Category dialog appears. 

4. Name the object Allowable_Sports and click OK. 




5. Select Sports URLs. Click Edit URLs. The Edit Locally Defined Category Object dialog appears. 
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6. Enter the URLs for the allowable sports Web sites and click OK. 




7. Under Policy, select Allowable_Sports; click OK. 

8. Repeat Steps 3 through 7, creating a category called Allowable_Entertainment with the URLs ew.com, 
rollingstone.com, and variety.com. 

9. Name the object Allowable PM IT Websites. Click OK twice to add the object to the rule. 
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Figure 14-29: Completed Second Rule in Layer 



To configure the Time Object: 

This example allows the specified users to access the sports and entertainment Web sites after 
business hours. 
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1. In the second rule, right-click the Time field and select Set; the Set Time Object dialog appears. 

2. Click New and select Time Object; the Add Time Object dialog appears. 
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3. Name the object After Hours. 

4. In the Specific Time of Day Restriction field, select Enable and set the time from 1 8:00 to 05:59. 
This defines after hours as 6:00 PM to 6:00 AM. 

5. In the Specific Weekday Restriction field, select Enable and select Monday, Tuesday, Wednesday, 
Thursday, and Friday. 

This defines the days of the week to which this rule applies. 

6. Click OK twice to add the Time Object to the rule. 
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To configure the Action object: 



File Edit Policy Configuration View Help 


Add Rule 
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In the second rule, right-click Action and select Allow. 
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This chapter provides conceptual information about ProxySG advanced policy features. While many 
Blue Coat Systems features have a policy component, some features have no configuration component 
outside policy. Configuring advanced policy is done by defining rules in the Visual Policy Manager 
(VPM) or by composing Content Policy Language (CPL). While some examples are provided in this 
chapter, references to the relevant VPM chapter component are included in each section. 

This chapter contains the following topics: 

□ "Blocking Pop Up Windows" 

o "Stripping or Replacing Active Content” 

□ "Modifying Headers” 

□ "Defining Exceptions” 

O "Managing Peer-to-Peer Services" 

Excluding exceptions, you must use policy to implement these capabilities. (For exceptions, you can 
create a list outside of policy to install on the system.) 
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Section A: Blocking Pop Up Windows 

This section describes the Blue Coat solution for blocking unwanted pop up windows. 

About Pop Up Blocking 

The ProxySG allows you to block pop up windows, which are usually in the form of unsolicited 
advertisements. Pop up windows are blocked by inserting Javascript code into each HTML Web page. 
Every time the Web page tries to open a new window, the code attempts to determine if the window is 
a result of user click. The window is allowed to open if the ProxySG determines a user clicked a button 
or link; otherwise, the window does not open. 

Limitations 

Because of the dynamic nature of the Web, blocking pop up windows is not a perfect solution. Keep in 
mind the following limitations before configuring this feature: 

□ Windows that contain desired or useful information cannot be distinguished from undesired 
content, such as advertisements. 

□ If the Web browser caches a page that spawns pop up windows before the blocking policy was 
installed, pop up ads continue to be served from that page regardless of current policy. 

□ Animated ads contained within Web pages are not blocked. Commonly seen in scrolling or 
drop-down form, these are not true pop up windows but are contained within the page. Users 
who see these ads might believe that pop up window blocking is not implemented. 

□ Pop up windows that are delivered through HTTPS are not blocked. 

□ Although the Blue Coat request headers tell a Web server not to use compression, it is possible 
(though not likely) for a Web server to be configured to send compressed responses anyway. The 
pop up blocking feature does not work on compressed HTML pages. 



Recommendations 

□ To compensate for limiting factors, administrators and users can override pop up blocking: 

• Administrators — Use VPM to create policy rules that exempt pop up blocking for specific 
Web sites and IP address ranges. For example. Blue Coat recommends disabling pop up 
blocking for your Intranet, which commonly resides on a IP address range. 

• Users — When a pop up window is blocked, a message is displayed in the status bar: 
blocked popup window -- use CTRL Refresh to see all popups . 

While pressing the Control key, click the Web browser Refresh button; the page is reloaded 
with pop up blocking disabled for that action. 

□ Create a separate Web Access policy layer for pop up blocking actions. This alleviates interference 
with Web applications deployed on your Intranet that require pop up windows. 

□ To prevent a cached Web page from spawning pop up windows, clear the browser cache, then 
reload the page without holding down the CTRL key. 
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Blocking pop up windows is accomplished through the Visual Policy Manager. See "Block/Do Not 
Block PopUp Ads" in Chapter 14: "The Visual Policy Manager" on page 567 for information about 
how to create blocking actions in a policy layers. 
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Section B: Stripping or Replacing Active Content 

This section describes the Blue Coat solution for stripping or replacing unwanted active content. 



About Active Content 

Scripts activated within Web pages can pose a security concern. The ProxySG policy can be configured 
to supplement standard virus scanning of Web content by detecting and removing the HTML tags 
that launch active content such as Java applets or scripts. In addition, the removed content can be 
replaced with predefined material, a process referred to as active content transformation. 

When the ProxySG is configured to perform active content transformation, Web pages requested by a 
client are scanned before they are served and any specified tags and the content they define are either 
removed or replaced. Since the transformed content is not cached, the transformation process is based 
on a variety of conditions, including time of day, client identity, or URL. 



Note: Pages served over an HTTPS tunneled connection are encrypted, so the content cannot be 

modified. 



The following tags and related content can be removed or replaced: 

□ <APPLET> — Java applets, as defined by HTML <applet> elements. 

□ < EMBED > — Embedded multimedia objects displayed using Netscape Navigator plug-ins as 
defined by HTML <embed> elements. 

□ <OBJECT> — Embedded multimedia objects displayed using Internet Explorer Active-X controls 
and other multimedia elements, as defined by HTML <ob j ect> elements 

□ <SCRIPT> — Embedded Javascript and VBScript programs, whether these are represented as 
HTML < script > elements. Javascript entities. Javascript URLs, or event handler attributes. The 
<noscript> tag is not affected by this features. 

Stripping active content is accomplished through the Visual Policy Manager or by composing CPL. 

□ See "Strip Active Content" in Chapter 14: "The Visual Policy Manager" on page 567 for 
information about how to create a strip active content object in a Web Access policy layer. 

□ Refer to the Bine Coat ProxySG Content Policy Language Guide. 

About Active Content Types 

The following sections provide more detail about the types of active content that can be removed or 

replaced. 

Script Tags 
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Scripts are generally placed between the start and end tags <SCRIPT> and </SCRIPT>. The type of 
script used is defined by the LANGUAGE attribute; for example, <SCRIPT LANGUAGE=" JavaScript 
1 . 0 " >). When the language attribute is undefined, the browser assumes JavaScript. 
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When transform active_content is configured to remove scripts, the basic operation is to 
remove all content between and including <SCRIPT> and </SCRIPT>, regardless of the language 
type, and substitute any defined replacement text. A notable exception occurs when a script is defined 
in the header portion of the HTML document (defined by the <HEAD> tag). In this case, the script is 
simply removed. This is because images, objects, and text are not allowed in the header of an HTML 
document. If the end script tag </SCRIPT> is missing from the document (the end of the document is 
defined as either up to the < /BODY > or </HTML> tag, or the last character of the document), then all 
content from the start <SCRIPT> tag to the end of the document is removed. 

JavaScript Entities 

JavaScript entities have the following format: & { j avascript code } and are found anywhere in the 
value part of an attribute (that is, <IMG SRC=" &{ images . logo } ;"). You can define more than one 
entity in the value portion of the attribute. When transform active_content is configured to 
remove scripts, all JavaScript entities attribute/ value pairs are removed. No replacement text is put in 
its place. 

JavaScript Strings 

JavaScript strings have the following format: j avascript : j avascript code and are found 
anywhere in the value part of an attribute, though usually only one of them can be defined in an 
attribute. Most modern browsers support JavaScript strings. When transform active_content is 
configured to remove scripts, all JavaScript string attribute/value pairs are removed. No replacement 
text is put in its place. 

JavaScript Events 

JavaScript events are attributes that start with the keyword on. For example, < A HREF= " index . html 
onMouseOver=" j avascript code" >. The HTML 4.01 specification defines 21 different JavaScript 
events: 

onBlur, onChange, onClick, onDblClick, onDragDrop, onFocus, onKeyDown, 
onKeyPress, onKeyUp, onLoad, onMouseDown, onMouseMove, onMouseOut, 
onMouseOver, onMouseUp, onMove, onReset, OnResize, onSelect, onSubmit, 
onUnload 

Both Microsoft Internet Explorer and Netscape have defined variations on these events as well as 
many new events. To catch all JavaScript events, the active content transformer identifies any attribute 
beginning with the keyword on, not including on itself. For example, the attribute onDonner in the 
tag <A HREF=" index . html" onDONNER="DONNER" > is removed even though onDonner does not 
exist as a valid JavaScript event in the browser. In this case, the transformed file would show <A 
HREF=" index . html" >. 
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Embed Tags 

HTML < EMBED > tags are not required to have an </ EMBED > end tag. Many Web browsers do, 
however, support the <EMBED> < /EMBED> tag pair. The text between the tags is supposed to be 
rendered by the browsers when there is no support for the embed tag, or if the MIME-type of the 
embed object is not supported. Thus, when transform active_content is configured to 
transform embed tags, only the <EMBED> tag is removed and replaced with any replacement text. Any 
occurrence of the end tag </ EMBED > is simply removed, leaving the text between the beginning and 
end tags intact. 

Object Tags 

Objects tags have a start <OBJECT> and end </OBJECT> tag pair, and the attributes CODETYPE and 
type determine the type of object. The text between the tags is supposed to be rendered by the 
browsers when the object tag is not supported, so when transform active_content is 
configured to transform object tags, only the <OBJECT> and </OBJECT> tags are removed and 
replaced with any replacement text. The text between the tags remains. The CODETYPE or TYPE 
attributes do not affect the transformation. Also, if the end < /OBJECT> tag is missing, the 
transformation will not be affected. 
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Section C: Modifying Headers 

The request headers are sent when users access Web objects that contain a lot of information. This can 
raise a concern that such details compromise the privacy or security of the enterprise or user. 

When a user clicks on a link, the Web browser sets the request's Referer header to the URL of the Web 
page that contained the link. (This header is not set if the URL was entered or selected from a favorites 
or bookmarks list.) If an internal Web page provides links to external Web sites, users clicking those 
links sends the URL of the internal pages, and are logged in the Web logs of those external sites. This is 
not usually an issue; however, if the external Web site is a competitor Web site or another site with 
interest in the internal details of your enterprise, this might be a concern. 

For example, how you structure your intranet might suggest something about your company's 
current or future direction. Certain project names or codewords might show up in directory or file 
names. Exposing the structure of the intranet makes it easier for hackers to attack the network. 

The broad solution of deleting Referer headers from all requests presents a problem because some 
Web sites do not serve images or other linked objects unless the Referer header is set to a referring 
page on that same Web site. The solution implemented by Blue Coat is to strip the Referer header only 
when the target Web page resides on the Internet and the referring page is on an internal host. 

Suppressing headers is accomplished through the Visual Policy Manager or by composing CPL. 

□ See "Suppress Pleader" in Chapter 14: "The Visual Policy Manager" on page 567 for information 
about how to create a strip active content object in a Web Access policy layer. 

□ Refer to the Blue Coat ProxySG Content Policy Language Guide. 
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Section D: Defining Exceptions 

Exceptions (formerly called message or RMG pages) are sent in response to certain ProxySG client 
requests, such as denial by policy, failure to handle the request, and authentication failure. Exceptions 
are returned to users based on policy rules defined by the ProxySG administrator. For example, if a 
client sends a request for content that is not allowed, an exception HTML page (for HTTP 
connections) or an exceptions string (for non-HTTP connections) is returned, informing the client that 
access is denied. 

Two types of exceptions are used: built-in and user-defined. 

Built-in Exceptions 

Built-in exceptions are a set of pre-defined exceptions contained on the ProxySG. Built-in exceptions 
send information back to the user under operational contexts that are known to occur, such as 
policy _denied or invalid_request. 

Built-in exceptions are always available and can also have their contents customized; however, 
built-in exceptions cannot be deleted, and you cannot create new built-in exceptions. 

The table below lists the built-in exceptions and the context under which they are issued. 



Table 15.1: Built-in Exceptions 



Exception Type 


Issued When 


authentication failed 


The transaction cannot be authenticated, usually because the 
credentials were incorrect, authentication failedis 
a synonym for deny . unauthorized. 


authentication failed password 
expired 


The authentication server reports that the credentials 
provided have expired, and a new password must be 
obtained. 


authentication_mode_not_supported 


The configured authentication mode is not supported for the 
current request. 


authentication redirect from 
virtual_host 


Transparent redirect authentication is being used. This 
exception redirects the transaction from the virtual 
authentication host to the original request. 


authentication redirect off box 


The request is being redirected to an authentication service 
on another device. 


authentication redirect to virtual 
host 


Transparent redirect authentication is being used. This 
exception redirects the transaction to the virtual 
authentication host. 


authentication success 


Transparent redirect authentication with cookies is being 
used. This exception redirects the transaction to the original 
request, but removes the authentication cookie form the 
request URL. 
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Table 15.1: Built-in Exceptions (Continued) 



Exception Type 


Issued When 


authorization failed 


The deny . unauthorized policy action is matched. This 
exception notifies the user that their currently authenticated 
identity is not permitted to perform the requested operation, 
but they might have some other credentials that would allow 
their request through (for example, they get an opportunity 
to enter new credentials). 


client failure limit exceeded 


Too many requests from your ip address 
($ (client . address) ) have failed. 


configuration error 


A configuration error on the Proxy SG was detected, and the 
requested operation could not be handled because of the 
configuration error. This exception is a likely indicator that 
the administrator of the ProxySG must intervene to resolve 
the problem. 


connect method denied 


A user attempted an CONNECT method to a non-standard 
port when explicitly proxied. Blue Coat does not allow 
CONNECT methods to non-standard ports by default 
because it is considered a security risk to do so. 


content filter denied 


A particular request is not permitted because of its content 
categorization. 


content filter unavailable 


An external content-filtering service could not be contacted, 
and the ProxySG is failing closed in such a situation. 


dns server failure 


The request could not be processed because the ProxySG was 
unable to communicate with the DNS server in order to 
resolve the destination address of the request. 


dns unresolved hostname 


The request could not be processed because the ProxySG was 
unable to resolve the hostname in the request with DNS. 


dynamic_bypass_reload 


The dynamic bypass policy action is matched. 


gateway error 


There was a network error while attempting to communicate 
with the upstream gateway. 


icap communication error 


A network error occurred while the ProxySG was attempting 
to communicate with an external ICAP server. 


internal error 


The ProxySG encountered an unexpected error that resulted 
in the inability to handle the current transaction. 


invalid auth form 


The submitted authentication form is invalid. The form data 
must contain the username, password, and valid original 
request information. 
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Table 15.1: Built-in Exceptions (Continued) 



Exception Type 


Issued When 


invalid request 


The request received by the ProxySG was unable to handle 
the request because it detected that there was something 
fundamentally wrong with the syntax of the request. 


license expired 


The requested operation cannot proceed because it would 
require the usage of an unlicensed feature. 


method denied 


The requested operation utilizes a method that has been 
explicitly denied because of the service properties associated 
with the request. 


not implemented 


The protocol cannot handle the requested operation because 
it utilizes a feature that is not currently implemented. 


notify 


Used internally by VPM. You do not need to customize the 
text of this exception, since in this case the entire HTML 
response is generated by VPM and is not taken from the 
exception definition. 


notify missing cookie 


This exception is returned when a VPM Notify User action is 
being used to notify the user, and the user has disabled 
cookies in the Web browser. 


policy denied 


policy denied is a synonym for deny . 


policy redirect 


A redirect action is matched in policy. 


redirect ed_stored_requests_not_ 
supported 


This applies to forms authentication with POST requests 
only): The origin server returned a redirect for the request. 
The ProxySG is configured to not allow stored requests to be 
redirected. 


refresh 


A refresh (using the HTTP Refresh: header) is 
required. The refresh exception (by default) refreshes the 
originally requested URL (or in some cases, its post-imputed 
form). 


server request limit exceeded 


Too many simultaneous requests are in progress to 
$(url.host). 


silent denied 


An exception ( silent denied) is matched in policy. 
This exception is pre-defined to have no body text, and is 
silent in that it results in only the status code being sent to the 
client. 


ssl domain invalid 


There was a failure contacting an upstream host through 
HTTPS because the certificate presented by the upstream 
host was either the incorrect one or invalid. 
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Table 15.1: Built-in Exceptions (Continued) 



Exception Type 


Issued When 


ssl_failed 


A secure connection could not be established to an upstream 
host. This is typically because the upstream host is not 
configured to accept SSL connections. 


tcp error 


A network error occurred attempting to communicate with 
an upstream host. 


transformation error 


The server sends an unknown encoding and the ProxySG is 
configured to do content transformation. 


unsupported encoding 


The client makes a request with an Accept - Encoding : 
Identity ; q= 0 , ... header. Only uncompressed content 
is available in cache, the ProxySG is not configured to 
compress the content, or the compression license is expired, 
or the client request results in to Accept - Encoding : 
Identity; q= 0 because of the combination of request and 
configured policy. 


unsupported_protocol 


The protocol used in the request is not understood. 



Most of the above exceptions can be initiated directly through the policy exception property 
However, some require additional state that makes initiating them either problematic or out of 
context. The following are exceptions that cannot be initiated through the exception property: 



□ 


authentication failed 




□ 


authentication_f ailed_password_expired 


□ 


authentication redirect 


from virtual host 


□ 


authentication redirect 


_to_virtual_host 


□ 


authentication_success 




□ 


dynamic_bypass_reload 




□ 


license expired 




□ 


ssl domain invalid 




□ 


ssl_f ailed 





To view the content of a built-in exception, enter the following commands at the ( conf ig ) prompt: 
SGOS# (config) exceptions 

SGOS# (config exceptions) show exceptions configuration_error 
conf iguration_error exception: 
all protocols: 
summary text : 

ProxySG configuration error 
details text: 

Your request could not be processed because of a configuration error: 

$ (exception. last_error) 



715 



Blue Coat ProxySG Configuration and Management Guide 



Section D: Defining Exceptions 



help text : 

The problem is most likely because of a configuration error, 

$ (exception. contact) and provide them with any pertinent information from 
this message, 
http protocol: 
code: 403 

User-Defined Exceptions 

User-defined exceptions are created and deleted by the administrator. If a user-defined exception is 
referenced by policy, it cannot be deleted. The default HTTP response code for user-defined 
exceptions is 403. 



Note: For users who are explicitly proxied and use Internet Explorer to request an HTTPS URL, 

an exception body longer than 900 characters might be truncated. The workaround is to 
shorten the exception body. 



An exception body less than 512 characters might cause a page does not exist 404 error. If this occurs, 

use the exception . autopad (yes | no) property to pad the body to more than 513 characters. For 

more information on the exception . autopad property, refer to the Blue Coat ProxySG Content Policy 

Language Guide. 

About Exception Definitions 

Each exception definition (whether built-in or user-defined) contains the following elements: 

□ Identifier — Identifies the type of exception. Table 15.1 on page 712 lists the built-in exception 
types. For user-defined exceptions, the identifier is the name specified upon creation. 

□ Format — Defines the appearance of the exception. For an HTTP exception response, the format is 
an HTML file. For other protocols, where the user agents are not able to render HTML, the format 
is commonly a single line. 

□ Summary — A short description of the exception that labels the exception cause. For example, the 
default policy_denied exception summary is "Access Denied". 

□ Details — The default text that describes reason for displaying the exception. For example, the 
default policy_denied exception (for the HTTP protocol) detail is: Your request has been 
denied by system policy. 

□ Help — An informative description of common possible causes and potential solutions for users to 
take. For example, if you want the categorization of a URL reviewed, you can append the 

$ (exception . category_review_url ) and $ (exception . category_review_message) 
substitutions to the $ (exception . help) definition. You must first enable this capability 
through content filtering configuration. For information on enabling review categorization, see 
"Selecting Category Providers" on page 787. 
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□ Contact — Used to configure site-specific contact information that can be substituted in all 
exceptions. Although it is possible to customize contact information on a per-exception basis, 
customizing the top-level contact information, which is used for all exceptions, is sufficient in 
most environments. 

□ HTTP - Code — The HTTP response code to use when the exception is issued. For example, the 
pol icy_denied exception by default returns the 4 03 Forbidden HTTP response code. 



Important: Fields other than Format must be less than 8000 characters. If they are greater than 
this, they are not displayed. 



When defining the above fields, you can use substitution variables that are particular to the given 
request. Some of the above fields are also available as substitutions: 

□ $ (exception . id) 

□ $ (exception . summary) 

□ $ (exception. details) 

□ $ (exception . help) 

□ $ (exception. contact) 

Additionally, the Format, Summary, Details, Help and Contact fields can be configured 
specifically for HTTP, or configured commonly for all protocols. 

The Format field, the body of the exception, is not available as a substitution. However, the Format 
field usually includes other substitutions. For example, the following is a simple HTML format: 

<html> 

<title>$ (exception . id) : $ (exception . summary) </title> 

<bodyxpre> 

Request: $ (method) $(url) 

Details: $ (exception . details ) 

Help: $ (exception . help) 

Contact: $ (exception. contact) 

</prex/bodyx/html> 

Some additionally useful substitutions related to exceptions are: 

□ $ (exception . last_error) — For certain requests, the ProxySG determines additional details 
on why the exception was issued. This substitution includes that extra information. 

□ $ ( exception . reason) — This substitution is determined internally by the ProxySG when it 
terminates a transaction and indicates the reason that the transaction was terminated. For 
example, a transaction that matches a DENY rule in policy has its $ ( exception . reason ) set to 
"Either 'deny' or 'exception' was matched in policy". 
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About the Exceptions Hierarchy 

Unlike the error pages in previous SGOS releases, exceptions are not required to have its entire 
contents defined. Exceptions are stored in a hierarchical model, and parent exceptions can provide 
default values for child exceptions. There are two parent exceptions from which other exceptions are 
derived: exception . all and exception . user-defined . all. 

Each built-in and user-defined exception derives its default values from the all exception. For 
example, by default the built-in exceptions do not define the format field. Instead, they depend on 
the all exception's format field definition. To change the format text for all built-in and user-defined 
exceptions, customize the format field for the all exception. 

The user -defined .all exception is the parent of all user-defined exceptions, but it is also a child of 
the all exception. Configuring exception . user-defined .all is only necessary if you want 
certain fields to be common for all user-defined exceptions, but not common for built-in exceptions. 

The following example demonstrates using the exception inline command to configure the 
$ (exception . contact ) substitution for every HTTP exception: 

# (config exceptions) inline http contact EOF 
For assistance, contact <a 

href = "mail to : sysadmin@example . com" >sysadmin</a>EOF 

The following example configures a different $ (exception . contact) substitution for every HTTP 
exception: 

# (config exceptions) user-defined inline http contact EOF 
For assistance, contact <a 

href = "mailto : policyadmin@example . com" >policyadmin< /a>EOF 

About the Exceptions Installable List 

The Exceptions Installable List uses the Structured Data Language (SDL) format. This format provides 
an effective method to express a hierarchy of key/value pairs. For example, the following is SDL file 
before customization: 

(exception . all 

(format "This is an exception: $ (exception . details )" ) 

(details " " ) 

( exception . policy_denied 
(format "") 

(details "your request has been denied by system policy") 

) 

This SDL file defines an exception called policy_denied that defines the 

$ (exception . details) substitution as "Your request has been denied by system 
policy". Because the exception does not define the format field, it inherits the format field from its 
parent exception (exception . all). When the policy_denied exception is issued, the resulting 
text is: This is an exception: your request has been denied by system policy. 

Suppose you want to customize the $ ( exception . contact ) substitution for every HTTP 
exception. Edit the exception . all component. 
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Note: The default HTTP format and built-in exception definitions have been removed for 

example purposes. 



(exception . all 

(contact "For assistance, contact your network support team.") 

(details " " ) 

(format "$ (exception . id) : $ (exception . details) " ) 

(help "") 

( summary " " ) 

(http 

(code "200") 

(contact "") 

(details " " ) 

(format <<EOF 
< format removed? 

EOF 

) 

(help "") 

( summary " " ) 

) 

<built-in exceptions removed? 

) 

To add the $ ( exception . contact ) information, modify the contact substitution under the http 
node: 

(exception . all 

(contact "For assistance, contact your network support team.") 

(details " " ) 

(format "$ (exception . id) : $ (exception . details) " ) 

(help "") 

( summary " " ) 

(http 

(code "200") 

(contact "For assistance, contact <a 

href = "mailto : sysadmin@example . com" >sysadmin< /a> " ) EOF 
(details "") 

(format <<EOF 

< format removed? 

EOF 



(help " " ) 

(summary "") 

<built-in exceptions removed? 

) 

) 

Keep in mind the following conditions when modifying exception installable lists: 

□ Every exception installable list must begin with a definition for exception . all. 
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□ In the exceptions' installable list, all definitions must be enclosed by 
exception . all and its accompanying closing parenthesis; that is, 

(exception . all 

(exception . policy_denied) 

) 

□ Keep the definition strings under the enclosed parentheses short, no longer than one line if 
possible. 

□ Blue Coat strongly recommends downloading the existing exceptions installable list, then 
modifying it. 

Creating or Editing Exceptions 

You can create or edit an exception with the CLI or with installable lists on the Management Console. 



Note: You cannot create user-defined exceptions for Patience Pages. 



http -code numeric 



inline ? 



To Create or Edit an Exception through the CLI 

1. At the (config) prompt, enter the following commands: 

SGOS# (config) exceptions 

SGOS# (config exceptions) create definition_name 
SGOS# (config exceptions) edit definition_name 
SGOS# (config exceptions user-defined . definition_name) 

HTTP 

response code 

SGOS# (config exceptions user-defined . definition_name) 
contact Set the $ (exceptions . contact) substitution 
details Set the $ (exceptions . details) substitution 
format Set the format for this exception 
help Set the $ (exceptions . help) substitution 

http Configure substitution fields for just HTTP exceptions 

summary Set the $ (exception . summary) substitution 
SGOS# (config exceptions user-defined. definition_name) 
string eof 

SGOS# (config exceptions user-defined. definition_name) 
string eof 

SGOS# (config exceptions user-defined. definition_name) 
string eof 

SGOS# (config exceptions user-defined. definition_name) 
string eof 

SGOS# (config exceptions user-defined definition_name) 
string eof 

2. (Optional) View the results. 



inline 


contact 


eof 


inline 


details 


eof 


inline 


format 


eof 


inline 


help eof 


inline 


summary 


eof 
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SGOS# (config exceptions user-defined. test) show exceptions user-defined . test 
$ (exception. id) : 
test 

$ (exception. summary) : 

Connection failed 
$ (exception. details) : 

Connection failed with stack error 
$ (exception . contact ) : 

Tech Support 

To Delete a User-Defined Exception: 

From the (config) prompt, enter the following commands: 

SGOS# (config) exceptions 

SGOS# (config exceptions) delete except ion_name 
ok 



Note: You cannot delete a user-defined exception that is referenced by policy. You must 

remove the reference to the exception from the policy before deleting the exception. 



Using the Management Console to Create and Install an Exceptions List 

The Management Console allows you to create and install exceptions with the following methods: 

□ Using the ProxySG Text Editor, which allows you to customize the existing exceptions file. 

□ Creating a local file on your local system; the ProxySG can browse to the already-created file and 
install it. 

□ Using a remote URL, where you place an already-created exceptions list on an FTP or PITTP 
server to be downloaded to the ProxySG. 



Note: A message is written to the event log when you install a list through the ProxySG. 



When the Exceptions file is customized, it updates the existing exceptions already on the ProxySG. 
The configuration remains in effect until it is overwritten by another update; it can be modified or 
overwritten using CLI commands. 
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To Install an Exceptions Definition through the Management Console 
1. Select Configuration>Policy>Exceptions. 



Exceptions 

r Install Exceptions 



Install Exceptions Definition from: 



Remote URL v 



Install 



- View Exceptions 

View File: 



Current Exceptions 



View 



Figure 15-1: Selecting the Exceptions Definitions Download Method 



Note: Click View to examine the existing definitions: Current Exceptions, Default Exceptions 

Source, Exceptions Configuration, and Results of Exception Load. 



2. From the Install Exceptions Definitions From drop-down list, select the method used to install the 
exceptions configuration; click Install. 

• Remote URL: 

Enter the hilly-qualified URL, including the filename, where the configuration is located. To 
view the file before installing it, click View. Click Install. View the installation status; click OK. 




Figure 15-2: Specifying the Remote Location of an Exceptions Configuration 
• Local File: 

Click Browse to bring up the Local File Browse window. Browse for the file on the local 
system. Open it and click Install. When the installation is complete, a results window opens. 
View the results, close the window, and click Close. 
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Figure 15-3: Specifying the Local Location of a Exception Definition 

Viewing Exceptions 

You can view the exceptions defined on the ProxySG, including how the defined HTML appears to 
users. The following are the viewable defined exception components: 

□ Current Exceptions — Displays all of the exceptions as they are currently defined. 

□ Default Exceptions Source — Displays the default ProxySG exceptions. 

□ Exceptions Configuration — Displays a page from which you can click links to view how exceptions 
appear in HTML to users. 

□ Results of Exception Load — Displays the results of the last installable list load, including any errors 
and warning to be fixed. 

To View Exceptions through the Management Console 

1. Select Configuration>Policy>Exceptions. 

2. From the View Exceptions Definitions From drop-down list, select the page to view; click View. 

• Text Editor: 

The current configuration is displayed in installable list format. You can customize it or delete 
it and create your own. Click Install. When the installation is complete, a results window 
opens. View the results, close the window, and click Close. 



723 




Blue Coat ProxySG Configuration and Management Guide 



Section D: Defining Exceptions 




Figure 1 5-4: Using the ProxySG Text Editor 



3. Click Apply. 



724 




Chapter 15: Advanced Policy 



Section E: Managing Peer-to-Peer Services 



Section E: Managing Peer-to-Peer Services 

This section describes the Blue Coat solution for managing and blocking peer-to-peer traffic. 



About Peer-to-Peer Communications 

The use of peer-to-peer (P2P) technologies and services consumes an estimated 60% of broadband ISP 
bandwidth. By design, most P2P services are port-agnostic, which makes attempting to block them at 
the firewall extremely difficult. One peer finds another IP address and port that is willing to share the 
file, but different peers can use different ports. Furthermore, P2P is not based on any standards, which 
makes it nearly impossible for network administrations to control or even detect. 

Although P2P provides some practical business uses in enterprises, unmanaged P2P activity creates 
risks: 

□ Excessive bandwidth consumptions affects mission-critical applications. 

□ Exponential security risk of exposure to viruses, spy wa re, and other malicious content. 

□ The threat of legal action concerning the unlawful downloading of copyrighted music and 
movies. 

Managing P2P is a dynamic challenge, as the administrator must be able to evaluate both P2P use and 
enterprise requirements. 



The Blue Coat Solution 

The ProxySG recognizes P2P activity relating to P2P file sharing applications. By constructing policy, 
you can control, block, and log P2P activity and limit the bandwidth consumed by P2P traffic. 



Note: Neither caching nor acceleration are provided with this feature. 



Supported Services 

This version of SGOS supports the following P2P services: 

□ FastTrack (Kazaa) 

□ EDonkey 

□ BitTorrent 

□ Gnutella 

Note: Refer to the Release Notes for the most current list of P2P services and versions the 

ProxySG supports. 
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Deployment 

To effectively manage P2P activity, the ProxySG must be deployed to intercept outbound network 
traffic and the firewall configured to block outbound connections that are not initiated by the 
ProxySG. 

Notes: 

n The ProxySG intercepts outbound TCP network connections, as routed through an L4 switch or a 
ProxySG in bridging mode. 

□ Configure ProxySG HTTP, SOCKS, and TCP tunnel services for destination ports to be monitored. 

□ Create firewall rules that allow only outbound connections that are initiated by the ProxySG. 

□ You can block all known P2P ports and define policy to stop P2P traffic attempting to come 
through over HTTP. 



Note: This features does not include additional configurations for intercepting or controlling 

UDP traffic. 



Policy Control 

This section lists the policy used to manage P2P. 

VPM Support 

The following VPM components relate to P2P control: 

□ Web Access Layer; Source column; P2P Client object. See "P2P Client" on page 601. 

□ Web Access Layer, Service column; Client Protocols. See "Client Protocol" on page 613. 

CPL Support 
CPL Triggers 

□ http . connect= {yes | no} 

□ p2p . client= {yes | no | bittorrent | edonkey | fasttrack | gnutella} 

CPL Properties 

□ force_protocol ( ) 

□ detect_protocol .protocol (yes | no) 

□ detect_protocol . [protocol 1, protocol2 , ...] (yes | no) 

□ detect_protocol (all | none) 

□ detect_protocol (protocoll , protocol2 , ...) 
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Where protocol is: http, bittorrent, edonkey, f asttrack, or gnutella. 

The default is detect_protocol (all) . 

Support CPL 

The following properties can be used in conjunction with the P2P-specific CPL: 

□ allow, deny, force_deny 

□ access_server (yes | no) — If the value is determined as no, the client is disconnected. 

□ authenticate (realm) — Unauthenticated clients are disconnected. 

□ socks_gateway (alias_list | no) 

□ socks_gateway . fail_open (yes | no) 

□ forward (alias_list) | no) — Only forwarding hosts currently supported by TCP tunnels 
are supported. 

□ forward . fail_open (yes | no) 

□ ref lect_ip (auto | no [ client | vip | ip_address) 

For complete CPL references, refer to the Blue Coat ProxySG Content Policy Language Guide. 

Policy Example 

The following policy example demonstrates how to deny network traffic that the ProxySG recognizes 
as P2P: 

<proxy> 

p2p . client=yes deny 

Proxy Authentication 

While P2P protocols do not support native proxy authentication, most P2P clients support SOCKS v5 
and HTTP 1.1 proxies. P2P proxy authentication is supported only for clients using these protocols 
(that are configured for proxy authentication). 

For information about proxy authentication, see "Section B: Controlling Access to the Internet and 
Intranet" on page 323. For a list of P2P clients suspected of not supporting SOCKS v5 with 
authentication, see the Release Notes for this release. 

Access Logging 

P2P activity is logged and reviewable. See Chapter 20: "Access Logging" on page 887. 
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This chapter contains the following sections: 

□ "Section A: About Streaming Media” — Provides streaming media terminology, general concepts, 
and information, such as player limitations and supported formats. 

□ "Section B: Configuring Streaming Media” — Provides feature-related concepts and procedures for 
configuring the ProxySG to manage streaming media applications and bandwidth. 

n "Section C: Windows Media Player" — Describes how to configure the Windows Media client and 
describes associated limitations and access log conventions. 

□ "Section D: RealPlayer” — Describes how to configure the Real Media client and describes 
associated limitations and access log conventions. 

n "Section E: QuickTime Player" — Describes how to configure the QuickTime client and describes 
associated limitations and access log conventions. 

Related Topics: 

□ Chapter 5: "Managing Port Services" on page 151 

□ Chapter 6: "Configuring Proxies" on page 181 

□ Chapter 22: "Statistics" on page 973 
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Section A: About Streaming Media 

This section contains the following topics: 

□ "Streaming Media Overview" 

□ "Windows Media Streaming” 

□ "Real Media Streaming" 

□ "QuickTime Streaming" 

□ "Streaming Media Authentication" 

□ "Streaming Media Caching Behavior" 

Streaming Media Overview 

Streaming is a method of content delivery. With media streaming, video and audio are delivered over 
the Internet rather than the user having to wait for an entire file to be downloaded before it can be 
played. 

Streaming media support on the ProxySG provides the following features: 

□ Streaming media files can be live or prerecorded. 

□ Employs flexible delivery methods: unicast, multicast, HTTP, TCP, and UDP 

□ Ability to seek, fast-forward, reverse, and pause. 

□ Ability to play entire file and control media playback, even before it is downloaded. 

□ Adjust media delivery to available bandwidth, including multi-bit-rate and thinning support. 

Important: The ProxySG streaming media components require valid licenses. For more 
information, see Chapter 2: "Licensing" on page 47. 



Supported Streaming Media Clients 

The ProxySG supports Microsoft Windows Media, RealNetworks RealPlayer, and Apple QuickTime 

clients. The specific protocols are discussed in "Windows Media Streaming” on page 731. 

Delivery Method 

The ProxySG supports the following streaming delivery methods: 

□ Unicast — A one-to-one transmission, where each client connects individually to the source, and a 
separate copy of data is delivered from the source to each client that requests it. Unicast supports 
both TCP- and UDP-based protocols. The majority of streaming media traffic on the Internet is 
unicast. 

□ Multicast — Allows efficient delivery of streaming content to a large number of users. Multicast 
enables hundreds or thousands of clients to play a single stream, thus minimizing bandwidth use. 
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The Proxy SG provides caching, splitting, and multicast functionality. 

Serving Content 

Using the ProxySG for streaming delivery minimizes bandwidth use by allowing the ProxySG to 
handle the broadcast and allows for policy enforcement over streaming use. The delivery method 
depends on if the content is live or video-on-demand. 

Live Unicast Content 

A ProxySG can serve many clients through one unicast connection by receiving the content from the 
origin server and then splitting that stream to the clients that request it. This method saves server-side 
bandwidth and reduces the server load. You cannot pause or rewind live broadcasts. A live broadcast 
can be of prerecorded content. A common example is a company president making a speech to all 
employees. 

Video-on-Demand Unicast Content 

A ProxySG can store frequently requested data and distribute it upon client requests. Because the 
ProxySG is closer to the client than the origin server, the data is served locally, which saves firewall 
bandwidth and increases quality of service by reducing pauses or buffering during playback. The 
ProxySG provides higher quality streams (also dependent on the client connection rate) than the 
origin server because of its closer proximity to the end user. VOD content can be paused, rewound, 
and played back. Common examples include training videos or news broadcasts. 

Multicast Content 

The ProxySG can take a unicast stream from the origin media server and deliver it as a multicast 
broadcast. This enables the ProxySG to take a one-to-one stream and split it into a one-to-many 
stream, saving bandwidth and reducing the server load. It also produces a higher quality broadcast. 

For Windows Media multicast, an NSC file is downloaded through HTTP to acquire the control 
information required to set up content delivery. 

For Real Media, multicasting maintains a TCP control (accounting) channel between the client and 
media server. The multicast data stream is broadcast using UDP from the ProxySG to streaming 
clients, who join the multicast. 

Windows Media Streaming 

The ProxySG supports both MMS and RTSP (SGOS 4.2.3 and later) streaming using the following 
Windows Media protocols. 

Client-Side 

□ MMS-UDP (Microsoft Media Streaming — User Data Protocol). 

□ MMS-TCP (Microsoft Media Streaming — Transmission Control Protocol). 

□ Multicast UDP — No TCP control connection exists for multicast delivery. 

□ RTP over unicast UDP (RTSP over TCP, RTP over unicast UDP) 
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□ RTP over TCP (RTSP over TCP and RTP over TCP on the same connection) 

□ HTTP streaming 

Server-Side 

n MMS-TCP (Microsoft Media Streaming — Transmission Control Protocol). 

□ RTP over TCP (RTSP over TCP and RTP over TCP on the same connection). 

Note: Server-side RTP over UDP is not supported. If policy directs the RTSP proxy to use HTTP 

as server-side transport, the proxy will deny the client request. The client then switches to 
MMS or HTTP. 

□ Multicast UDP 

□ HTTP streaming 

Supported Windows Media Players and Servers 

The ProxySG supports the following versions and formats: 

□ Windows Media Player 6.4, 7, 9, and 10 

□ Windows Media Server 4.1 

□ Windows Media Server 9 

Windows Media Player Failover 

Windows Media Players version 9 and later attempts to connect using the transports and ports listed 
in the following list, in order of precedence. 

1. RTSP (TCP 554) 

2. MMS (TCP 1755) 

3. HTTP (TCP 80) 

Delivery Protocol Descriptions 

The following briefly describes each of the supported delivery protocols: 

□ Multicast-UDP 

□ MMS-UDP — UDP provides the most efficient network throughput from server to client. The 
disadvantage to UDP is that many network administrators close their firewalls to UDP traffic, 
limiting the potential audience for Multicast-UDP-based streams. 

If an MMS-UDP session cannot be established, the client falls back to MMS-TCP automatically. 

The ProxySG then establishes a connection to the origin server running the Microsoft Windows 
Media service. 
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□ MMS-TCP — TCP provides a reliable protocol for delivering streaming media content from a 
server to a client. At the expense of less efficiency compared to MMS-UDP data transfer, 
MMS-TCP provides a reliable method for streaming content from the origin server to the 
ProxySG. 



Note: The MMS protocol is usually referred to as either MMS-TCP or MMS-UDP depending on 

whether TCP or UDP is used as the transport layer for sending streaming data packets. 
MMS-UDP uses a TCP connection for sending and receiving media control messages, and 
a UDP connection for streaming the actual media data. MMS-TCP uses TCP connections 
to send both control and data messages. 



□ RTP over Unicast UDP — When this transport is used RTP (Real-Time Transport Protocol) is 
delivered over unicast UDP and RTSP is delivered over TCP. This transport is supported only 
from the ProxySG to clients. UDP transport is more efficient but is often disallowed by firewalls. 

□ RTP over TCP — This transport delivers RTP and RTSP over the same TCP connection. This 
transport can be on either the client-side or server-side. 

□ HTTP Streaming — The Windows Media server also supports HTTP-based media control 
commands along with TCP-based streaming data delivery. This combination has the benefit of 
working with all firewalls that let only Web traffic through (TCP port 80). 

No protocol relationship exists between the ProxySG and the media server or between the ProxySG 

and the client. 



RTSP Support 

SGOS 4.2.3 and later supports RTSP protocol for streaming Windows Media content. If the ProxySG is 
downgraded to a release prior to SGOS 4.2.3, RTSP connections from a Windows Media Player are 
denied. However, the client fails over to MMS or HTTP. 

Viewing Windows Media (MMS, HTTP, RTSP) Statistics 

□ Summary statistics in the Management Console 

Navigate to Statistics>Streaming Statistics>Windows Media to view the summary statistics. 

□ Detailed statistics 

The combined (MMS and RTSP) Windows Media detailed statistics are available by accessing the 
Advanced URLs link currently used for MMS detailed statistics: 

Show active URLs (detailed file statistics) https: / /ProxySG-ip: 8082/MMS/file-stats?* 

Show server statistics (detailed server statistics) https: //Proxi/SG-zp:8082/MMS/server-stats?* 
Show client statistics (detailed client statistics) https:/ /Pnm/SG-zp:8082/MMS/client-stats?* 
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Real Media Streaming 

The ProxySG supports the following Real Media protocols: 

Client-Side 

n RDT over unicast UDP (RTSP over TCP, RDT over unicast UDP) 

□ Interleaved RTSP (RTSP over TCP, RDT over TCP on the same connection) 

□ RDT over multicast UDP (RTSP over TCP, RTP over multicast UDP; for live content only) 

□ HTTP streaming (RTSP and RTP over TCP tunneled through HTTP) — HTTP streaming is 
supported through a handoff process from HTTP to RTSP HTTP accepts the connection and, 
based on the headers, hands off to RTSP The headers identify an RTSP URL. 

Server-Side 

n Interleaved RTSP 

□ HTTP streaming 

Unsupported Protocols 

The following Real Media protocols are not supported in this version of SGOS: 

□ PNA. 

□ Server-side RDT/ UDP (both unicast and multicast). 

Supported Real Media Players and Servers 

The ProxySG supports the following versions: 

□ RealQne Player, version 2 

□ RealPlayer 8 and 10 

□ RealServer 8 through 10 

□ Helix Universal Server 



Note: Blue Coat recommends not deploying a Helix proxy in between the ProxySG and a Helix 

server where the Helix proxy is the parent to the ProxySG. This causes errors with the 
Helix server. The reverse is acceptable (using a Helix proxy as a child to the ProxySG). 



QuickTime Streaming 

The ProxySG supports the following protocols: 

□ RTP over unicast UDP (RTSP over TCP, RTP over unicast UDP) 

□ Interleaved RTSP (RTSP over TCP, RTP over TCP on the same connection) 
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□ HTTP streaming (RTSP and RTP over TCP tunneled through HTTP) — HTTP streaming is 
supported through a handoff process from HTTP to RTSP. HTTP accepts the connection and, 
based on the headers, hands off to RTSP. The headers identify an RTSP URL. 

Server-Side 

□ Interleaved RTSP 

□ HTTP streaming 

Unsupported Protocols 

The following QuickTime protocols are not supported in this version of SGOS: 

□ Server-side RTP/UDP, both unicast and multicast, is not supported. 

□ Client-side multicast is not supported. 

Supported QuickTime Players and Servers 

The ProxySG supports the following versions, but in pass-through mode only: 

□ QuickTime Players 6.x and 5.x 

□ Darwin Streaming Server 4.1.x and 3.x. 

□ Helix Universal Server 

Streaming Media Authentication 

The following sections discuss authentication between streaming media clients and ProxySG 
appliances and between ProxySG appliances and origin content servers (OCS). 

Windows Media Server-Side Authentication 

Windows Media server authentication for HTTP and MMS supports the authentication types listed in 
the following table. 



Table 16.2: Supported Windows Media Server Authentication Types 





BASIC and Membership 
Service Account 


BASIC and IWA 


IWA 


Digest 


HTTP 


Yes 


Yes 


Yes 


No 


MMS 


Yes 


Yes 


Yes 


No 


RTSP 


Yes 


Yes 


Yes 


Yes 



Note: IWA: Microsoft Windows Integrated Windows Authentication (IWA) Account Database. 
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The ProxySG supports the caching and live-splitting of server-authenticated data. The functionality is 
also integrated with partial caching functionality so that multiple security challenges are not issued to 
the Windows Media Player when it accesses different portions of the same media file. 

When Windows Media content on the server is accessed for the first time, the ProxySG caches the 
content along with the authentication type enabled on the server. The cached authentication type 
remains until the appliance learns that the server has changed the enabled authentication type, either 
through cache coherency (checking to be sure the cached contents reflect the original source) or until 
the ProxySG connects to the origin server (to verify access credentials). 

Authentication type on the server refers to the authentication type enabled on the origin server at the 
time when the client sends a request for the content. 

Windows Media Proxy Authentication 

If proxy authentication is configured, Windows Media clients are authenticated based on the policy 
settings. The proxy (the ProxySG) evaluates the request from the client and verifies the accessibility 
against the set policies. The Windows Media player then prompts the client for the proper password. 
If the client is accepted, the Windows Media server might also require the client to provide a 
password for authentication. If a previously accepted client attempts to access the same Windows 
Media content again, the ProxySG verifies the user credentials using its own credential cache. If 
successful, the client request is forwarded to the Windows Media server for authentication. 

Windows Media Player Authentication Limitations 

Consider the following proxy authentication limitations with the Windows Media player (except 
when specified, these do not apply to HTTP or RTSP streaming): 

□ If the proxy authentication type is configured as BASIC and the server authentication type is 
configured as IWA, the default is denial of service. 

□ If proxy authentication is configured as IWA and the server authentication is configured as 
BASIC, the proxy authentication type defaults to BASIC. 

□ The ProxySG does not support authentication based on url_path or url_path_regex conditions 
when using rams as the url_scheme. 

□ Transparent style HTTP proxy authentication fails to work with Windows Media players when 
the credential cache lifetime is set to 0 (independent of whether server-side authentication is 
involved). 

□ If proxy authentication is configured, a request for a stream through HTTP prompts the user to 
enter access credentials twice: once for the proxy authentication and once for the media server 
authentication. 
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□ Additional scenarios involving HTTP streaming exist that do not work when the TTL is set to zero 
(0), even though only proxy authentication (with no server authentication) is involved. The 
ProxySG returning a 401-style proxy authentication challenge to the Windows Media Player 6.0 
does not work because the Player cannot resolve inconsistencies between the authentication 
response code and the server type returned from the ProxySG. This results in an infinite loop of 
requests and challenges. Example scenarios include transparent authentication — resulting from 
either transparent request from player or hard-coded service specified in the ProxySG — and 
request of cache-local (ASX-rewritten or unicast alias) URLs. 

Real Media Proxy Authentication 

If proxy authentication is configured. Real Media clients are authenticated based on the policy 
settings. The proxy (the ProxySG) evaluates the request from the client and verifies the accessibility 
against the set policies. Next, RealPlayer prompts the client for the proper password. If the client is 
accepted, the Real Media server can also require the client to provide a password for authentication. If 
a previously accepted client attempts to access the same Real Media content again, the ProxySG 
verifies the user credentials using its own credential cache. If successful, the client request is 
forwarded to the Real Media server for authentication. 

Real Media Player Authentication Limitation 

Using RealPlayer 8.0 in transparent mode with both proxy and Real Media server authentication 
configured to BASIC, RealPlayer 8.0 always sends the same proxy credentials to the media server. 
This is regardless of whether a user enters in credentials for the media server. Therefore, the user is 
never authenticated and the content is not served. 

QuickTime Proxy Authentication 

BASIC is the only proxy authentication mode supported for QuickTime clients. If an IWA challenge is 
issued, the mode automatically downgrades to BASIC. 
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Streaming Media Caching Behavior 

The following sections describe how the ProxySG and SGOS process and store streaming media 
requests. Discussed are caching, video on demand (VOD), live splitting, bit rate support, and 
pre-populating content. 

Streaming Media Caching Behavior 
Windows Media 

The ProxySG caches Windows Media-encoded video and audio files. The standard extensions for 
these file types are: . wmv, . wma, and . asf . 

Real Media 

The ProxySG caches Real Media-encoded files, such as RealVideo and RealAudio. The standard 
extensions for these file types are: .ra, .rm, and .rmvb. Other content served from a Real Media server 
through RTSP is also supported, but it is not cached. This content is served in pass-through mode 
only. 

QuickTime 

The ProxySG does not cache QuickTime content ( . mov files). All QuickTime content is served in 
pass-through mode only. 

Video On Demand (VOD) 

The ProxySG supports the caching of files for VOD streaming. First, the client connects to the 
ProxySG, which in turn connects to the origin server and pulls the content, storing it locally. 
Subsequent requests are served from the ProxySG. This provides bandwidth savings, as every hit to 
the ProxySG means less network traffic. Blue Coat also supports partial caching of streams. 



Note: On-demand files must be unicast. 



Live Splitting 

The ProxySG supports splitting of live content, but behavior varies depending upon the media type. 

For live streams, the ProxySG can split streams for clients that request the same stream. First, the 
client connects to the ProxySG, which then connects to the origin server and requests the live stream. 
Subsequent requests are split from the appliance. 

Two streams are considered identical by the ProxySG if they share the following characteristics: 

□ The stream is a live or broadcast stream. 

□ The URL of the stream requested by client is identical. 

□ MMS, MMSU, MMST, and HTTP are considered identical. 
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□ RTSP, RTSPU, and RTSPT are considered identical. 

Splitting of live unicast streams provides bandwidth savings, since subsequent requests do not 
increase network traffic. 

Multiple Bit Rate Support 

The ProxySG supports multiple bit rate (MBR), which is the capability of a single stream to deliver 
multiple bit rates to clients requesting content from caches from within varying levels of network 
conditions (such as different connecting bandwidths and traffic). This allows the ProxySG and the 
client to negotiate the optimal stream quality for the available bandwidth even when the network 
conditions are bad. MBR increases client-side streaming quality, especially when the requested 
content is not cached. 

Only the requested bitrate is cached. Therefore, a media client that requests a 50Kbps stream receives 
that stream, and the Blue Coat ProxySG caches only the 50Kbps bitrate content. 

BitrateThinning 

Thinning support is closely related to MBR, but different in that thinning allows for data rate 
optimizations even for single data-rate media files. If the media client detects that there is network 
congestion, it requests a subset of the single data rate stream. For example, depending on how 
congested the network is, the client requests only the key video frames or audio-only instead of the 
complete video stream. 

Server-Side Playlist 

Windows Media servers version 9 and later includes server-side playlists. 



Note: A server-side playlist is a SMIL file (.wsx extension) interpreted by the server. 



Each playlist entry is announced by the server through a stream change request. Both broadcast (live) 
and on-demand (VOD) publishing points on the server can stream content from server-side playlists. 

Windows Media RTSP supports server-side playlists. It can split live streams created using a 
server-side playlist. However, caching of server-side playlists or the individual VOD elements of a 
server-side playlist are not supported; these are handled in pass-through mode only. 

Note that server-side playlists with a single item in the playlist is supported for multicast station, but 
server-side playlists with multiple items are not supported. 
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Pre-Populating Content 

The ProxySG supports pre-population of streaming files from HTTP servers and origin content 
servers. Downloading streaming files from HTTP servers reduces the time required to pre-populate 
the file. 



Note: QuickTime content is not supported. Windows Media RTSP only supports pre-population 

of streaming files from origin content servers. However, whenever origin content server 
allows faster caching of streaming content, Windows Media RTSP pre-populates the 
content much faster. 



Pre-population can be accomplished through streaming from the media server. The required 
download time was equivalent to the file length; for example, a two-hour movie required two hours to 
download. Now, if the media file is hosted on a HTTP server, the download time occurs at normal 
transfer speeds of an HTTP object, and is independent of the play length of the media file. 



Note: Content must be hosted on a HTTP server in addition to the media server. 



Using the content distribute CLI command, content is downloaded from the HTTP server and 
renamed with a given URL argument. A client requesting the content perceives that the file originated 
from a media server. If the file on the origin media server experiences changes (such as naming 
convention), SGOS bypasses the cached mirrored version and fetches the updated version. 
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Section B: Configuring Streaming Media 

This section contains the following topics: 

□ "Limiting Bandwidth" 

□ "Configuring the Refresh Rate" 

□ "Configuring HTTP Handoff" 

□ "Forwarding Client Logs to the Media Server” 

□ "Configuring Media Server Authentication Type (Windows Media)" 

□ "About Multicast Streaming" 

□ "Managing Multicast Streaming for Windows Media" 

□ "Managing Multicast Streaming for Real Media" 

□ "Managing Simulated Live Content (Windows Media)" 

□ "ASX Rewriting (Windows Media)" 

□ "About Fast Streaming (Windows Media)" 

Related Topics 

You must also configure the network service (Configuration>Network>Services) to assign port numbers 
and modes (transparent or proxy). For more information, see Chapter 6: "Configuring Proxies" on 
page 181. 

Limiting Bandwidth 

The following sections describe bandwidth limitation and how to configure the ProxySG to limit 
global and protocol-specific media bandwidth. 

About Bandwidth Limitation 

Streaming media bandwidth management is achieved by configuring the ProxySG to restrict the total 
number of bits per second the appliance receives from the origin media servers and delivers to clients. 
The configuration options are flexible to allow you to configure streaming bandwidth limitations for 
the ProxySG, as well as for each streaming protocol (Windows Media, Real Media, and QuickTime). 



Note: Bandwidth claimed by HTTP, non-streaming protocols, and network infrastructure is not 

constrained by this limit. Transient bursts that occur on the network can exceed the hard 
limits established by the bandwidth limit options. 



Once configured, the ProxySG limits streaming access to the specified threshold. If a client tries to 
make a request after a limit has been reached, the client receives an error message. 
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Consider the following features when planning to limit streaming media bandwidth: 

□ ProxySG to server (all protocols) — The total kilobits per second allowed between the appliance 
and any origin content server or upstream proxy for all streaming protocols. Setting this option to 
0 effectively prevents the ProxySG from initiating any connections to the media server. The 
ProxySG supports partial caching in that no bandwidth is consumed if portions of the media 
content are stored in the ProxySG. 

□ Client to ProxySG (all protocols) — The total kilobits per second allowed between streaming clients 
and the ProxySG. Setting this option to 0 effectively prevents any streaming clients from initiating 
connections through the ProxySG. 

□ ProxySG to server — The total kilobits per second allowed between the Appliance and the media 
server. Setting this option to 0 effectively prevents the ProxySG from accepting media content. 

Limiting ProxySG bandwidth restricts the following streaming media-related functions: 

• Live and video-on-demand media, the sum of all bit rates 

• Limits the ability to fetch new data for an object that is partially cached 

• Reception of multicast streams 

□ Client to ProxySG — The total kilobits per second allowed between Windows Media streaming 
media clients and the ProxySG. Setting this option to 0 effectively prevents streaming clients from 
making connections to the ProxySG. 

Limiting server bandwidth restricts the following streaming media-related functions: 

• MBR is supported; the ProxySG assumes the client is using the maximum bit rate 

• Limits the transmission of multicast streams 

□ Client connections — The total number of clients that can connect concurrently. Once this limit is 
reached, clients attempting to connect receive an error message and are not allowed to connect 
until other clients disconnect. Setting this variable to 0 effectively prevents any streaming media 
clients from connecting. 

Choosing a Method to Limit Streaming Bandwidth 

You can control streaming bandwidth using two different methods: you can use the streaming 
features described below, or you can use the bandwidth management features described in Chapter 
10: "Bandwidth Management" on page 489. You should not, however, use both methods to control 
streaming bandwidth. The way that each method controls bandwidth differs — read the information 
below to decide which method works best for you. 

Limiting streaming bandwidth using the streaming features (described in this section) works this 
way: if a new stream comes in that pushes above the specified bandwidth limit, that new stream is 
denied. This allows existing streams to continue to get the same level of quality they currently receive. 
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Limiting streaming bandwidth using the bandwidth management features (described in Chapter 10: 
"Bandwidth Management" on page 489) works this way: all streaming traffic for which you have 
configured a bandwidth limit shares that limit. If a new stream comes in that pushes above the 
specified bandwidth limit, that stream is allowed, and the amount of bandwidth available for existing 
streams is reduced. This causes streaming players to drop to a lower bandwidth version of the stream. 
If a lower bandwidth version of the stream is not available, players that are not receiving enough 
bandwidth can behave in an unpredictable fashion. In other words, if the amount of bandwidth is 
insufficient to service all of the streams, some or all of the media players experience a reduction in 
stream quality. 

For most circumstances. Blue Coat recommends that you use the streaming features to control 
streaming bandwidth rather than the bandwidth management features. 

Configuring Bandwidth Limitation — Global 

This section describes how to limit all bandwidth use through the ProxySG. 

To Specify the Bandwidth Limit for all Streaming Protocols through the Management Console 
1. Select Configuration>Services>Streaming Proxies>General. 

General | Windows Media | WMedia Bandwidth | Real Media ; < | ► 

- Bandwidth 

f~l Limit client bandwidth to: kilobits/sec 

n Limit gateway bandwidth to: kilobits/sec 



r Multicast 



Maximum hops: 


16 








IP range: 


224 | 2 


| 128 | 0 


to 224 1 2 


| 255 | 255 












Port range: 


32768 




to 65535 







Apply 


Cancel 


Help 



Figure 16-1: Streaming Media General Tab 
2. To limit the client connection bandwidth: 



Note: This option is not based on individual clients. 



a. In the Bandwidth pane, enable the Limit client bandwidth to checkbox. 

b. In the Kilobits/sec field, enter the maximum number of kilobits per second that the 
ProxySG allows for all streaming client connections. 

3. To limit the ProxySG (origin server/ upstream connection) bandwidth: 
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a. In the Bandwidth pane, enable the Limit gateway bandwidth to checkbox. 

b. In the Kilobits/sec field, enter the maximum number of kilobits per second that the 
ProxySG allows for all streaming connections to origin media servers. 

To Specify Bandwidth Limit for all Streaming Protocols through the CLI 

To limit the client connection bandwidth, at the (conf ig) command prompt, enter the following 
command: 

SGOS# (config) streaming max-client-bandwidth kbits_second 

To limit the ProxySG (origin server /upstream connection) bandwidth, at the (config) command 
prompt, enter the following command: 

SGOS# (config) streaming max-gateway-bandwidth kbits_second 



Note: To allow maximum client bandwidth, use the streaming windows-media no 

max-client-bandwidth or the streaming windows-media no 
max-gateway-bandwidth command. 



Configuring Bandwidth Limitation — Protocol-Specific 

This section describes how to limit bandwidth use per-protocol (Windows Media and Real Media) 
through the ProxySG. 

To Specify the Bandwidth Limit for Windows Media, Real Media, or QuickTime through the 
Management Console 

1. Select Configuration>Services>Streaming Proxies>WMedia Bandwidth or RMedia Bandwidth or QuickTime 
Bandwidth. 

2. To limit the bandwidth for client connections to the ProxySG: 

a. Enable the Limit client bandwidth to checkbox. 

b. In the Kilobits/sec field, enter the maximum number of kilobits per second that the 
ProxySG allows for all streaming client connections. 

3. To limit the bandwidth for connections from the ProxySG to origin content servers: 

a. Enable the Limit gateway bandwidth to checkbox. 

b. In the Kilobits/sec field, enter the maximum number of kilobits per second that the 
ProxySG allows for all streaming connections to origin media servers. 

To Specify the Bandwidth Limit for Windows Media, Real Media, or QuickTime through the CLI 

To limit the client connection bandwidth, at the (config) prompt, enter the following command: 

SGOS# (config) streaming {windows-media | real-media | quicktime} 
max- client -bandwidth kbits_second 

To limit the ProxySG (origin server /upstream connection) bandwidth, at the (config) command 
prompt, enter the following command: 
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SGOS# (config) streaming {windows -media | real-media | quicktime} 
max -gateway -bandwidth kbits_second 



Note: To allow maximum client bandwidth, use the streaming windows-media no 

max-client-bandwidth or the streaming windows-media no 
max-gateway-bandwidth command. 



Configuring Bandwidth Limitation — Fast Start (WM) 



Note: This section applies to Windows Media only. 



This section describes how to configure the maximum bandwidth (in kilobytes per second) each 
Windows Media Player can start with. Upon connection to the ProxySG, streaming media clients do 
not consume more bandwidth (in kilobits per second) than the defined value. 

To Specify the Maximum Starting Bandwidth through the CLI 

At the (config) prompt, enter the following command: 

SGOS# (config) streaming windows-media max- fast-bandwidth kbps 

Maximum Connections 

This section describes how to configure the maximum number of streaming clients, on a per-protocol 
basis, that can connect to the ProxySG. 

To Specify the Maximum Number of Client Connections through the Management Console 

1. Select Configuration>Services>Streaming Proxies>WMedia Bandwidth or Real Media Bandwidth or 
QuickTime Bandwidth. 

2. To limit the bandwidth for connections from the ProxySG to Windows Media origin servers: 

a. Select Limit maximum connections. 

b. In the clients field, enter the total number of clients that can connect concurrently. 

To Specify the Maximum Number of Client Connections through the CLI 

At the (config) prompt, enter the following command: 

SGOS# (config) streaming {windows-media | real-media | quicktime} 
max-connections number 



Note: To allow maximum number of connections, invoke the streaming {windows -media 

| real-media | quicktime} no max- connection command. 
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Configuring the Refresh Rate 

The refresh feature specifies the length of time before cached streaming content is checked for 
freshness. 

The default is never refresh. Blue Coat recommends that you change this setting. 

To Set the Refresh Rate through the Management Console 

1. Select Configuration>Services>Streaming Proxies>Windows Media or Real Media. 

2. Perform one of the following: 

a. In the Check freshness every n.nn hours field, enter the length of time before the cached 
streaming content is checked for freshness. 

b. To force the ProxySG to check every time for freshness, select Check freshness every access. 

3. Click Apply. 

To Set the Refresh Rate through the CLI 

At the (config) prompt, enter the following commands: 

SGOS# (config) streaming {windows -media | real-media} refresh-interval 

number . number 

where number . number is the length of time before the cached streaming content should be 
checked for freshness. 



Note: A value of 0 requires the streaming content to always be checked for freshness. 



To disable freshness checking, enter the following command: 

SGOS# (config) streaming {windows -media | real-media} no ref resh- interval 

Configuring HTTP Handoff 

HTTP handoff is enabled by default. This section describes HTTP handoff and how to disable the 
feature. 



About HTTP Handoff 

When a Windows Media, Real Media, or QuickTime client requests a stream from the ProxySG over 
port 80, which in common deployments is the only port allowing traffic through a firewall, the HTTP 
module passes control to the streaming module so HTTP streaming can be supported through the 
HTTP proxy port. 

The ProxySG supports HTTP streaming. It does not support HTTP downloading of media files from 
HTTP servers and their subsequent caching and serving as streaming files. An HTTP connection is 
established through port 80 that allows you to send streaming data from the origin server to the 
clients through the ProxySG. 
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Note: The default setting for HTTP Handoff is enabled. If you do not want HTTP streams to be 

cached or split, change this setting to disabled. 



Disabling HTTP Handoff 

To Disable HTTP Port Handoff through the Management Console 

1. Select Configuration>Services>Streaming Proxies>Windows Media or Real Media or QuickTime. 

2. Deselect Enable HTTP handoff. 

3. Click Apply. 

To Disable the HTTP Port Handoff through the CLI 

At the (config) prompt, enter the following command: 

SGOS# (config) streaming {windows -media | real-media | quicktime} http-handoff 
disable 

Forwarding Client Logs to the Media Server 

This section describes media server compatibility and how to forward client logs. 

About Forwarding Client Logs 

The ProxySG logs information, such as client IP address, the date, and the time, to the origin server for 
Windows Media and Real Media content. 



Note: For Real Media, the log is only forwarded before a streaming session is halted; QuickTime 

RTSP log forwarding is not supported. 



Logging to the origin server is supported for Windows Media content. (For more information on what 
is logged to the origin server, see Chapter 20: "Access Logging" on page 887). 

Logging messages are embedded in a log message sent to the content server when: 

□ The ProxySG receives an end-of-file notification. 

□ The Proxy SG-server connection is closed. 

□ A user stops the stream. The connection is not stopped; the same connection to the OCS remains 
and is used to send client information. This prevents starting another connection to the OCS. 

□ A user opens a new file without closing or stopping the current one. 

Windows Media only: 

□ A user seeks to a new position or uses fast forward or reverse. 
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□ A file is looped in a live scenario. Logging occurs whenever playing of a file ends before going on 
to play another. 

When the ProxySG receives a log record from the client, the appliance records the log in the access log 
and then forwards the log to the origin content server. 

Configuring the ProxySG to Forward Client Logs 

To Enable Forwarding Client-Generated Logging to the Origin Media Server through the Management 
Console 

1. Select Configuration>Services>Streaming Proxies>Windows Media or Real Media. 

2. Select Forward client-generated logs to origin media server. 

3. Click Apply. 

To Enable or Disable Forwarding Client-Generated Logging through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) streaming {windows -media | real-media} log- forwarding {enable | 
disable} 

To Enable or Disable Forwarding Client-Generated Logging through the CLI 

SGOS# (config) streaming {windows-media} log-compatibility {enable | disable} 

Configuring Media Server Authentication Type (Windows Media) 



Note: This section applies to Windows Media streaming only. 



Configure the ProxySG to recognize the type of authentication the origin content server is using: 
BASIC or NTLM/ Kerberos. 

To Configure the Media Server Authentication Type through the CLI 

At the (config) prompt, enter the following command: 

SGOS# (config) streaming windows-media server- auth- type {basic | ntlm} 
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About Multicast Streaming 

This section describes multicast streaming and how to configure the ProxySG to manage multicast 
broadcasts. 

About Serving Multicast Content 

□ How multicast content is handled through the ProxySG depends on whether the ProxySG is 
delivering Windows Media or Real Media multicast broadcasts (QuickTime is not supported). For 
Windows Media, the ProxySG takes a multicast stream from the origin server and delivers it as a 
unicast stream. This avoids the main disadvantage of multicasting — that all of the routers on the 
network must be multicast-enabled to accept a multicast stream. Unicast-to-multicast, 
multicast-to-multicast, and broadcast alias-(scheduled live from stored content)-to-multicast are 
also supported. 

□ For Real Media, the ProxySG takes a unicast stream from the origin RealServer and delivers it as a 
multicast stream. This enables the ProxySG to take a one-to-one stream and split it into a 
one-to-many stream, saving bandwidth and reducing the server load. 

Multicast to Unicast Live Conversion at the ProxySG 

The ProxySG supports converting multicast streams from an origin content server to unicast streams. 
The stream at the ProxySG is given the appropriate unicast headers to allow the appliance to direct 
one copy of the content to each user on the network. 

Multicast streaming only uses UDP protocol and does not know about the control channel, which 
transfers essential file information. The . nsc file (a file created off-line that contains this essential 
information) is retrieved at the beginning of a multicast session from an HTTP server. The 
multicast-alias command specifies an alias to the URL to receive this .nsc file. 

The converted unicast stream can use any of the protocols supported by Windows Media, including 
HTTP streaming. 

When a client requests the alias content, the ProxySG uses the URL specified in the multicast-alias 
command to fetch the . nsc file from the HTTP server. The . nsc file contains all of the 
multicast-related information, such as addresses and . asf file header information that is normally 
exchanged through the control connection for unicast-delivered content. 

Configuring the ProxySG Multicast Network 

This section describes how to configure the ProxySG multicast service. Additional steps are required 
to configure the ProxySG to serve multicast broadcasts to streaming clients (Windows Media and Real 
Media). Those procedures are provided in subsequent sections. 

To Configure the Multicast Service through the Management Console 

1. Select Configuration>Services>Streaming Proxies>General. 

2. In the Maximum Hops field, enter a time-to-live (TTL) value. 

3. In the IP Range fields, enter the IP address range. 
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4. In the Port Range fields, enter the port range. 

5. Enable Windows and Real Media multicast; see the next section, "Managing Multicast Streaming 
for Windows Media" and "Managing Multicast Streaming for Real Media" on page 754. 

Managing Multicast Streaming for Windows Media 

This section describes multicast station and . nsc files, and describes how to configure the ProxySG to 
send multicast broadcasts to Windows Media clients. 

About Multicast Stations 

A multicast station is a defined location from where the Windows Media player retrieves live streams. 
This defined location allows . asf streams to be delivered to many clients using only the bandwidth of 
a single stream. Without a multicast station, streams must be delivered to clients through unicast. 

A multicast station contains all of the information needed to deliver .asf content to a Windows 
Media player or to another ProxySG, including: 

□ IP address 

□ Port 

□ Stream format 

□ TTL value (time-to-live, expressed hops) 

The information is stored in an . nsc file, which the Window Media Player must be able to access to 
locate the IP address. 

If Windows Media Player fails to find proper streaming packets on the network for multicast, the 
player can roll over to a unicast URL. Reasons for this include lack of a multicast-enabled router on 
the network or if the player is outside the multicast station's TTL. If the player fails to receive 
streaming data packets, it uses the unicast URL specified in the . nsc file that is created from the 
multicast station configuration. All . nsc files contain a unicast URL to allow rollover. 

Unicast to Multicast 

Unicast to multicast streaming requires converting a unicast stream on the server-side connection to a 
multicast station on the ProxySG. The unicast stream must contain live content before the multicast 
station works properly. If the unicast stream is a video-on-demand file, the multicast station is created 
but is not able to send packets to the network. For video-on-demand files, use the broadcast -alias 
command, discussed below. 

Multicast to Multicast 

Use the multicast-alias command to get the source stream for the multicast station. 

About Broadcast Aliases 

A broadcast alias defines a playlist, specify a starting time, date, and the number of times the content 
is repeated. 
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Creating a Multicast Station 

To create a multicast station, you must perform the following: 

□ Define a name for the multicast station. 

□ Define the source of the multicast stream. 

□ The port range to be used. 

□ Define the address range of the multicast stream. 

□ Define the TTL value. 

□ Create the multicast alias, unicast alias, and broadcast alias commands to enable the functionality. 

Note: Use of alias is not supported for Windows Media RTSP. 



You must configure multicast stations through the CLI. 

Syntax 

multicast-station name { alias \ url} [ address \ port \ ttl ] 
where 

• name specifies the name of the multicast station, such as stationl. 

• {alias | url } defines the source of the multicast stream. The source can be a URL or it 
can be a multicast alias, a unicast alias, or simulated live. (The source commands must be 
set up before the functionality is enabled within the multicast station.) 

• [address | port [ ttl] are optional commands that you can use to override the 
default ranges of these values. (Defaults and permissible values are discussed below.) 

Example 1: Create a Multicast Station for M MS 

This example: 

□ Creates a multicast station, named stationl, on ProxySG 10.25.36.47. 

□ Defines the source as rams : //io .25 . 36 . 47/tenchi. 

□ Accepts the address, port, and TTL default values. 

SGOS# (config) streaming windows-media multicast-station stationl 
mms ://10.25.36. 47/tenchi . 

To delete multicast stationl: 

SGOS# (config) streaming no multicast-station stationl 

Example 2: Create a Multicast Station for Windows Media RTSP 

n Creates a multicast station, named stationl, on ProxySG 10.25.36.47. 

□ Defines the source as rtsp: //io .25.36. 47/tenchi. 

□ Accepts the address, port, and TTL default values. 
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SGOS# (config) streaming windows-media multicast-station stationl 
rtsp://10.25.36.47 / tenchi . 

Example 3: Create a Broadcast Alias and Direct a Multicast Station to use It 

This example: 

□ To allow unicast clients to connect through multicast, creates a broadcast alias named arrayl; 
defines the source as mms : //10 . 25 . 36 .48/tenchi2. 

□ Instructs the multicast station from Example 1, stationl, to use the broadcast alias, arrayl, as 
the source. 

SGOS# (config) streaming windows-media broadcast-alias arrayl 
mms : //10 . 25 . 36 . 48/tenchi2 0 today noon 

SGOS# (config) streaming windows-media multicast-station stationl arrayl 

Changing Address, Port, and TTL Values 

Specific commands allow you to change the address range, the port range, and the default TTL value. 
To leave the defaults as they are for most multicast stations and change it only for specified station 
definitions, use the multicast-station command. 

The multicast-station command randomly creates an IP address and port from the specified 
ranges. 

□ Address-range: the default ranges from 224 . 2 . 128.0 to 224. 2 . 255. 255; the permissible range is 
224.0.0.2 and 239.255.255.255. 

□ Port-range: the default ranges from 32768 to 65535; the permissible range is between 1 and 
65535. 

□ TTL value: the default is 5 hops; the permissible range is from 1 to 255. 

Syntax, with Defaults Set 

multicast address-range <224 . 2 . 128 . 0>-<224 . 2 . 255 . 255> 
multicast port-range <32768>-<65535> 
multicast ttl <5> 

Getting the .nsc File 

The . nsc file is created from the multicast station definition and saved through the browser as a text 
file encoded in a Microsoft proprietary format. 

Without an .nsc file, the multicast station definition does not work. 

To get an .nsc file from newly created stationl, open the file by navigating through the browser to the 
multicast station's location (where it was created) and save the file as stationl . nsc. 

The file location, based on the streaming configuration above: 
http://10.25.36. 4 7 /MMS /nsc/ stationl . nsc 

Save the file as stationl . nsc. 
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Note: You can also enter the URL in the Windows Media Player to start the stream. 



The newly created file is not editable; the settings come from streaming configuration file. In that file, 

you have already defined the following pertinent information for the file: 

□ The address, which includes TTL, IP Address, IP Port, Unicast URL, and the NSC URL. All 
created . nsc files contain a unicast URL for rollover in case the Windows Media Player cannot 
find the streaming packets. 

□ The description, which references the MMS URL that you defined. 

□ The format, which contains important ASF header information. All streams delivered by the 
multicast station definition have their ASF headers defined here. 



Monitoring the Multicast Station 

You can determine the multicast station definitions by viewing the streaming windows configuration. 
To determine the current client connections and current ProxySG connections, use the show 
streaming windows-media statistics command. 



To View the Multicast Station Setup through the CLI 

SGOS# (config) show streaming windows config 

; Windows Media Configuration 
license : 1XXXXXXX- 7XXXXXXX- 7XXXXX 

logging: enable 

logging enable 
http-handof f : enable 

live-retransmit : enable 

(1755) : enable 

0 



transparent -port 
explicit proxy: 
ref resh- interval : 
max connections: 
max-bandwidth : 
max-gateway-bandwidth : 
bandwidth) 
multicast address: 
multicast port: 
multicast TTL: 
asx-rewrite : 
multicast-alias : 
unicast-alias : 
broadcast-alias : 
multicast -station : 
40465 5 (playing) 



no refresh interval (Never check freshness) 
no max-connections (Allow maximum connections) 
no max-bandwidth (Allow maximum bandwidth) 
no max-gateway-bandwidth (Allow maximum 

224.2.128.0 - 224.2.255.255 
32768 - 65535 
5 

No rules 
No rules 
No rules 
No rules 

stationl mms : //10 . 25 . 36 . 47/tenchi 224.2.207.0 



Note: Playing at the end of the multicast station definition indicates that the station is 

currently sending packets onto the network. The IP address and port ranges have 
been randomly assigned from among the default ranges allowed. 
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To View the Multicast Station Statistics through the CLI 

SGOS# (config) show streaming windows stat 

/Windows Media Statistics 
Current client connections: 

by transport: 0 UDP, 0 TCP, 0 HTTP, 1 multicast 
by type: 1 live, 0 on- demand 
by proxy: 0 MMS, 0 RTSP 

Current gateway connections: 

by transport: 0 UDP, 1 TCP, 0 HTTP, 0 multicast 
by type: 1 live, 0 on -demand 
by proxy: 0 MMS, 0 RTSP 

Managing Multicast Streaming for Real Media 

This section describes how to configure Real Media multicast streaming. 

About Real Media Multicast Broadcasts 

The ProxySG receives a unicast stream from the origin RealServer and serves it as a multicast 
broadcast. This allows the ProxySG to take a one-to-one stream and split it into a one-to-many stream, 
saving bandwidth and reducing the server load. It also produces a higher quality broadcast. 

Multicasting maintains a TCP control (accounting) channel between the client and RealServer. The 
multicast data stream is broadcast using UDP from the ProxySG to RealPlayers that join the multicast. 
The ProxySG support for Real Media uses UDP port 554 (RTSP) for multicasting. This port number 
can be changed to any valid UDP port number. 

Enabling Real Media Multicast 

To Enable Multicast through the Management Console 

1. Select Configuration>Services>Streaming Proxies>RMedia Bandwidth. 

2. Select Enable multicast. 

3. Click Apply. 

To Set the Refresh Rate through the CLI 

At the (config) prompt, enter the following commands: 

SGOS# (config) streaming real-media multicast enable 

Managing Simulated Live Content (Windows Media) 

This section describes simulated live content and how to configure the ProxySG to manage and serve 
simulated live content. 



Note: This section applies only to Windows Media. 
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About Simulated Live Content 

The simulated live content feature defines playback of one or more video-on-demand files as a 
scheduled live event, which begins at a specified time. The content can be looped multiple times, or 
scheduled to start at multiple start times throughout the day. If used in conjunction with the 
multicast-alias command, the live content is multicast; otherwise, live content is accessible as 
live-splitting sources. The feature does not require the content to be cached. 

Once a starting date and time for the simulated live content have been set, the broadcast of the content 
starts when there is at least one client requesting the file. Clients requesting the simulated live content 
before the scheduled time are put into wait mode. Clients requesting the content after all of the 
contents have played receive an error message. Video-on-demand content does not need to be on the 
ProxySG before the scheduled start time, but prepopulating the content on the appliance provides 
better streaming quality. 

Before configuring simulated live, consider the following: 

□ The simulated live content name must be unique. Aliases are not case sensitive. 

□ The name cannot be used for both a unicast and a multicast alias name. 

□ Once simulated live content is referenced by one or more multicast stations, the simulated live 
content cannot be deleted until all multicast stations referencing the simulated live content are 
first deleted. 

The multicast station appears as another client of simulated live content, just like a Windows Media 
Player. 



Note: This note applies to HTTP only. If a client opens Windows Media player and requests an 

alias before the starting time specified in the broadcast -alias option, the HTTP 
connection closes after a short time period. When the specified time arrives, the player 
fails to reconnect to the stream and remains in waiting mode. 



Three scenarios can occur when a client requests the simulated live content: 

□ Clients connect before the scheduled start time of the simulated live content: clients are put into 
wait mode. 

□ Clients connect during the scheduled playback time of the simulated live content: clients receive 
cached content for playback. 

□ Clients connect after the scheduled playback time of the simulated live: the client receives an error 
message. 

The ProxySG computes the starting playtime of the broadcast stream based on the time difference 

between the client request time and the simulated live starting time. 
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Creating a Broadcast Alias for Simulated Live Content 

Syntax 

streaming windows-media broadcast-alias alias url loops date time 
where: 

• alias is the name of the simulated live content. 

• url is the URL for the video-on-demand stream. Up to 128 URLs can be specified for 
simulated live content. 

• loops is the number of times you want the content to be played back. Set to 0 (zero) to 
allow the content to be viewed an indefinite number of times. 

• date is the simulated live content starting date. Valid date strings are in the format 
yyyy-mm-dd or today. You can specify up to seven start dates by using the comma as a 
separator (no spaces). 

• time is the simulated live content starting time. Valid time strings are in the format hh : mm 
(on a 24-hour clock) or one of the following strings: 

— midnight , noon 

— lam, 2am, . . . 

— 1pm, 2pm, . . . 

Specify up to 24 different start times within a single date by using the comma as a 
separator (no spaces). 

Example 1 

This example creates a playlist for simulated live content. The order of playback is dependent on the 
order you enter the URLs. Up to 128 URLs can be added. 

SGOS# (config) streaming windows-media broadcast-alias alias url 

Example 2 

This example demonstrates the following: 

□ creates a simulated live file called bca. 

□ plays back mms : / / ocs . bca . com/bcal . asf and mms : / / ocs . bca . com/bca2 . asf . 

□ configures the ProxySG to play back the content twice. 

□ sets a starting date and time of today at 4 p.m., 6 p.m., and 8 p.m. 

SGOS# (config) streaming windows-media broadcast-alias bca 

mms : //ocs . bca . com/bcal . as f 2 today 4pm, 6pm, 8pm 

SGOS# (config) streaming windows-media broadcast-alias bca 

mms : / / ocs . bca . com/bca2 .asf 

To Delete Simulated Live Content: 

SGOS# (config) streaming windows-media no broadcast-alias alias 
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ASX Rewriting (Windows Media) 

This section describes ASX rewriting and applies to Windows Media only. 

About Fast Streaming (Windows Media) 



Note: This feature applies to Windows Media only. 



Windows Media Server version 9 and later contains a feature called Fast Streaming that allows clients 
to provide streams with extremely low buffering time. 

SGOS 4.x supports the following functionality for both cached and uncached content: 

□ Fast Start 

□ Fast Cache 

Fast Recovery and Fast Reconnect are currently not supported. 
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Section C: Windows Media Player 

This section describes how to configure the Windows Media Player client and describes associated 
limitations and access log conventions. 

Configuring Windows Media Player 

To apply the ProxySG Windows Media streaming services, Windows Media Player 6.4 or higher 
(Windows Media Player 9 is recommended) must be installed and configured to use explicit proxy. 

MMS explicit proxy is defined with the asx- rewrite command (discussed earlier in this chapter) or 
with CPL (url_host_rewrite). 



Note: The example below uses Windows Media Player 9.0. Installation and setup varies with 

different versions of Windows Media Player. 



To Configure Windows Media Player: 

1 . Start Windows Media Player. 

2. Select Tools>Options>Network. 




Figure 16-2: Configuring Windows Media Player Proxy 
3. In the Streaming proxy settings section, select MMS and click Configure. 
The Configure Protocol window displays for the selected protocol. 
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4. Select Use the following proxy server and enter the ProxySG IP address and the port number used for 
the explicit proxy (the default MMS port is 1755; the default RTSP port is 554). 

5. Click OK; click OK again to close the Options dialog. 

Limitations 

This section describes Windows Media Player limitations that might affect performance. 

Striding Limitations 

When you use the Windows Media Player, consider the following limitations in regard to using fast 
forward and reverse (referred to as striding ): 

□ If you request a cached file and repeatedly attempt play and fast forward, the file freezes. 

□ If you attempt a fast reverse of a cached file that is just about to play, you receive an error 
message, depending on whether you have a proxy: 

• Without a proxy: A device attached to the system is not functioning. 

• With a proxy: The request is invalid in the current state. 

□ If Windows Media Player is in pause mode for more than ten minutes and you press fast reverse 
or fast forward, an error message displays: The network connection has failed. 

Other Limitations 

□ Applies to Version 9: if a url_host_rewrite rule is configured to rewrite a host name that is a 
domain name instead of an IP address, a request through the MMS protocol fails and the host is 
not rewritten. As the connect message sent by the player at the initial connection does not contain 
the host name, a rewrite cannot occur. HTTP requests are not affected by this limitation. 

□ If explicit proxy is configured and the access policy on the ProxySG is set to deny, a requested 
stream using HTTP from Windows Media Player 9 serves the stream directly from the origin 
server even after the request is denied. The player sends a request to the OCS and plays the 
stream from there. 

Blue Coat recommends the following policy: 

<proxy> 

streaming . content=yes deny 
-or- 
<proxy> 

streaming . content=windows_media deny 

The above rules force the HTTP module to hand-off HTTP requests to the MMS module. MMS 
returns the error properly to the player, and does not go directly to the origin server to try to 
server the content. 
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□ If you request an un-cached file using the HTTP protocol, the file is likely to stop playing if the 
authentication type is set to BASIC or NTLM/ Kerberos and you initiate rapid seeks before the 
buffering begins for a previous seek. The Windows Media Player, however, displays that the file 
is still playing. 

□ If a stream is scheduled to be accessible at a future time (using a simulated live rule), and the 
stream is requested before that time, the Windows Media Player enters a waiting stage. This is 
normal. However, if HTTP is used as the protocol, after a minute or two the Windows Media 
Player closes the HTTP connection, but remains in the waiting stage, even when the stream is 
broadcasting. 



Note: For authentication-specific limitations, see "Windows Media Player Authentication 

Limitations". 



Windows Media Access Log Formats 

See Appendix B: "Access Log Formats" on page 1041. 

Troubleshooting Windows Media Player 6.4 

□ You must define the HTTP explicit proxy. 

□ If a url_host_rewrite rule is configured to rewrite a host name that is a domain name instead of 
an IP address, a request through the MMS protocol fails and the host is not rewritten. As the 
connect message sent by the player at the initial connection does not contain the host name, a 
rewrite cannot occur. HTTP requests are not affected by this limitation. 

□ If the media server is configured for IWA authentication, Windows Media Player 6.4 uses the 
credentials of the logged-on user to satisfy the challenged request. If the media server or proxy 
authentication type is IWA, configure the Windows Media server to accept logged-on user 
credentials. 

□ If proxy authentication is not configured and the media server is configured as BASIC and the 
user fails to provide a valid username and password, the user fails to receive another dialog box. 
Instead, the request fails to open the stream. 

□ If the origin server is made up of multiple servers, stream splitting sometimes does not occur 
because Windows Media player 6.4 does not send domain information to the ProxySG; the 
appliance can only split streams based on the host IP address. In addition, if the URL is composed 
of hostnames instead of IP addresses, splitting does not occur across WMP 6.4 and WMP 7.0 
clients. 

□ When a file is looped in a live scenario, Windows Media Player 6.4 does not log this instance. 

About ASX Rewrite 

The ProxySG provides proxy support for Windows Media Player 6.4, although the player itself does 

not support the specification of explicit proxies using the MMS protocol. 
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If your environment does not use a Layer 4 switch or the Cisco Web Cache Control Protocol (WCCP), 
the ProxySG can operate as a proxy for Windows Media Player 6.4 clients by rewriting the Windows 
Media metafile (which contains entries with URL links to the actual location of the streaming content) 
to point to the appliance rather than the Windows Media server. The metadata files can 
have .asx, .wvx,or . wax extensions, but are commonly referred to as . asx files. The . a sx file refers 
to the actual media files (with . asf, . wmv, and . wma extensions). An . asx file can refer to other . asx 
files, although this is not a recommended practice. If the file does not have one of the metafile 
extensions and the Web server that is serving the metadata file does not set the correct MIME type, it 
is not processed by the Windows Media module. Also, the . asx file with the appropriate syntax must 
be located on an HTTP (not Windows Media) server. 



Note: For ASX rewriting to occur, the player must be configured to use the ProxySG as the 

HTTP proxy. Configuring the browser only as the HTTP proxy is not sufficient. 



The ASX rewrite module is triggered by either the appropriate file extension or the returned MIME 
type from the server (x-video-asf). 



Note: If an . asx file syntax does not follow the standard <ASX> tag-based syntax, the ASX 

rewrite module is not triggered. 



For the ProxySG to operate as a proxy for Windows Media Player 6.4 requires the following: 

□ The client is explicitly proxied for HTTP content to the ProxySG that rewrites the . asx metafile. 

□ The streaming media ProxySG is configurable. 



Note: Windows Media Player automatically tries to roll over to different protocols according to 

its Windows Media property settings before trying the rollover URLs in the . asx 
metafile. 



With the asx- rewrite command, you can implement redirection of the streaming media to a 
ProxySG by specifying the rewrite protocol, the rewrite IP address, and the rewrite port. 

The protocol specified in the ASX rewrite rule is the protocol the client uses to reach the ProxySG. You 
can use forwarding and policy to change the default protocol specified in the original . asx file that 
connects to the origin media server. 

When creating ASX rewrite rules, you need to determine the number priority. It is likely you will 
create multiple ASX rewrite rules that affect the . asx file; for example, rule 100 could redirect the IP 
address from 10 . 25 . 36. 01 to 10 . 25 . 36.4 7 , while rule 300 could redirect the IP address from 
10 . 25 . 36.01 to 10. 25 . 36 . 58 . In this case, you are saying that the original IP address is redirected to 
the IP address in rule 100. If that IP address is not available, the ProxySG looks for another rule 
matching the incoming IP address. 
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Before creating rules, consider the following. 

□ Each rule you create must be checked for a match; therefore, performance might be affected if you 
create large amounts of rules. 

□ Lower numbers have a higher priority than high numbers. 



Note: Rules can only be created through the CLI. 



□ ASX rewrite rules configured for multiple ProxySGs configured in an HTTP proxy-chaining 

configuration can produce unexpected URL entries in access logs for the downstream ProxySG (the 
ProxySG that the client proxies to). The combination of proxy-chained ProxySGs in the HTTP path 
coupled with ASX rewrite configured for multiple ProxySGs in the chain can create a rewritten 
URL requested by the client in the example form of: 

protocoll : / / downstream_SecApp/ redirect? protocol2 : // <upstream_ 

SecApp>/ redirect? protocols : / / origin_host / origin_path 

In this scenario, the URL used by the downstream ProxySG for caching and access logging can be 
different than what is expected. Specifically, the downstream ProxySG creates an access log entry 
with protocol2 : //upstream_SecApp/redirect as the requested URL. Content is also cached 
using this truncated URL. Blue Coat recommends that the ASX rewrite rule be configured for only 
the downstream ProxySG, along with a proxy route rule that can forward the Windows Media 
streaming requests from the downstream to upstream ProxySGs. 

Syntax for the asx-rewrite Command: 

asx-rewrite rule # in-addr cache-proto cache-addr [cache-port] 
where: 

• in-addr — Specifies the hostname or IP address delivering the content 

• cache-proto — Specifies the rewrite protocol on the ProxySG. Acceptable values for the 
rewrite protocol are: 

— mmsu specifies Microsoft Media Streaming UDP 

— mmst specifies Microsoft Media Streaming TCP 

— http specifies HTTP 

— rams specifies either MMS-UDP or MMS-TCP 

— * specifies the same protocol as in the . asx file 

If the . asx file is referred from within another . asx file (not a recommended practice), 
use a * for the cache-proto value. This specifies that the protocol specified in the original 
URL is used. As a conservative, alternative approach, you could use HTTP for the 
cache -proto value. 

• cache-addr — Specifies the rewrite address on the ProxySG. 

• cache-port — Specifies the port on the ProxySG. This value is optional. 
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To Set Up the .asx Rewrite Rules through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) streaming windows-media asx-rewrite number in-addr cache-proto 
cache-addr cache-port 



Note: To delete a specific rule, enter streaming windows-media no asx-rewrite number. 

To ensure that an ASX rewrite rule has been modified immediately, clear the local browser cache. 

Example 

This example: 

□ Sets the priority rule to 200 

□ Sets the protocol to be whatever protocol was originally specified in the URL and directs the data 
stream to the appropriate default port. 

□ Provides the rewrite IP address of 10 . 9 . 44 . 53, the ProxySG. 

SGOS# (config) streaming windows-media asx-rewrite 200 * * 10.9.44.53 

Note: ASX files must be fetched from HTTP servers. If you are not sure of the network topology 

or the content being served on the network, use the asterisks to assure the protocol set is 
that specified in the URL. 



ASX Rewrite Incompatibility With Server-side IWA Authentication 

Server-side authentication (MMS only, not HTTP) is supported if the origin media server 
authentication type is BASIC or No Auth. However, if you know that a Windows Media server is 
configured for IWA authentication, the following procedure allows you to designate any virtual IP 
addresses to the IWA authentication type. If you know that all of the activity through the ProxySG 
requires IWA authentication, you can use the IP address of the appliance. 

To Designate an IP Address to an Authentication Type through the CLI 

1. If necessary, create a virtual IP address that is used to contact the Windows Media server. 

2. At the (config) prompt, enter the following command: 

SGOS# (config) streaming windows-media server- auth- type ntlm ip_address 

3. Configure the ASX rewrite rule to use the IP address. 

a. To remove the authentication type designation: 

SGOS# (config) streaming windows-media no server-auth- type ip_address 

b. To return the authentication type to BASIC: 

SGOS# (config) streaming windows-media server- auth- type basic ip_address 
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Section D: RealPlayer 

This section describes how to configure Real Player and describes associated limitations and access 
log formats. 

Configuring RealPlayer 

To use the ProxySG Real Media streaming services with an explicit proxy configuration, the client 
machine must have RealPlayer installed and configured to use RTSP streams. If you use transparent 
proxy, no changes need to be made to the RealPlayer. 

To Configure RealPlayer 



Note: This procedure features RealOne Basic, version 2.0. Installation and setup menus vary 

with different versions of RealPlayer. Refer to the RealPlayer documentation to configure 
earlier versions of RealPlayer. 



1 . Start RealPlayer. 

2. Select Tools>Preferences. 




Figure 16-3: RealOne Preferences Dialog 

3. Click Proxy. In the Streaming Setting section, click Change Settings; the Streaming Proxy Settings 
dialog appears. 

4. In the PNA and RTSP proxies: field, click Use Proxies and in the RTSP field enter the IP address of 
the proxy ProxySG. Also enter the RTSP port number (the default is 554). 
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Figure 16-4: Configuring the RealPlayer to Proxy through the ProxySG 

These settings must match the settings configured in the ProxySG. If you change the ProxySG 
explicit proxy configuration, you must also reconfigure the RealPlayer. 

5. For HTTP Proxy, if you have an HTTP proxy already configured in your browser, select Use system 
Internet Connection proxy settings. 

Note: If using transparent proxy, RTSP port 554 is set by default and cannot be changed. 

6. In the Do not use proxy for: section, you can enter specific hosts and bypass the ProxySG. 

Note: This can also be accomplished with policy, which is the recommended method. 

7. Click OK to close the Streaming Proxy Settings dialog. 

8. To configure RealPlayer transport settings, select Network Transports. 

9. Click RTSP Settings. 

The RTSP Transport Settings dialog appears. 
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Figure 16-5: Configuring RealPlayer RTSP Transport Settings 

10. Select the appropriate options, based on your network configuration. For example, if your firewall 
does not accept UDP, select Attempt to use TCP for all content. Blue Coat recommends using the 
default settings. 

11. Click OK. 

12. To allow the creation of access log entries, RealPlayer must be instructed to communicate with the 
RealServer. Perform one of the following or both as necessary: 

• RealPlayer 8 — Select View>Preferences>Support; click Send connection-quality data to RealServers; 
click OK. 

• RealOne Player — Select Tools>Preferences>lnternet Settings; in the Internet Settings field, click 
Send connection-quality data to RealServers; click OK. 

Real Media Access Log Formats 

See Appendix B: "Access Log Formats" on page 1041. 



Limitations and Known Issues 

For authentication-specific limitations, see "Real Media Player Authentication Limitation" on 
page 737. 
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Section E: QuickTime Player 

This section describes how to configure the QuickTime client and describes associated limitations and 
access log formats. 

Configuring QuickTime Player 

This section describes how to configure the QuickTime player for explicit proxy to the ProxySG. 

To Configure QuickTime: 

1. Select Edit>Preferences>QuickTime Preferences. 




Figure 16-6: Configuring the QuickTime Client Proxy 

2. Deselect Use System Settings. 

3. Select RTSP proxy server; enter the IP address of the ProxySG to connect to and the port number 
(554 is the default). 

These settings must match the settings configured in the ProxySG. If you change the ProxySG 
explicit proxy settings, set similar settings in RealPlayer. 

4. Close the dialog. 

QuickTime Access Log Formats 

See Appendix B: "Access Log Formats" on page 1041. 



Limitations 

For authentication-specific limitations, see "QuickTime Proxy Authentication” on page 737. 
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Access Log Format 

See Appendix B: "Access Log Formats" on page 1041. 
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This chapter discusses how to control Instant Messaging (IM) activity through the ProxySG. 

About Securing Instant Messaging 

Instant Messaging use in an enterprise environment creates security concerns because regardless of 
how network security is configured, IM connections can occur from any established protocol, such as 
HTTP or SOCKS, on any open port. Because it is common for coworkers to use IM to communicate, 
especially in remote offices, classified company information can be exposed outside the network. 
Viruses and other malicious code can also be introduced into the network from file sharing through IM 
clients. 

The ProxySG serves as an IM proxy. You can control IM actions by allowing or denying IM 
communications and file sharing based on users (both employee identities and IM handles), groups, 
file types and names, and other triggers. All IM communications can be logged and archived for 
review. 

The ProxySG supports the AOL, MSN, and Yahoo IM protocols. 

Recommended Deployments 

For large networks with unimpeded Internet access. Blue Coat recommends transparently redirecting 
the IM protocols to the ProxySG, which requires the ProxySG bridging feature or an L4 switch or 
WCCP 

For networks that do not allow outbound access. Blue Coat recommends using the SOCKS proxy and 
configuring policy and content filtering denials for HTTP requests to IM servers. 

About the Instant Messaging Protocol Services 

The ProxySG accepts connections for the supported IM protocols on ports specified in services. The 
following are the default service ports (transparent, but disabled): 

n AOL-IM: 5190 

□ MSN-IM: 1863 and 6891 
O Yahoo-IM: 5050 and 5101 
These ports are disabled by default. 

MSN port 1863 and Yahoo port 5050 are the default client login ports. MSN port 6891 and Yahoo port 
5101 are the default for client-to-client direct connections and file transfers. If these ports are not 
enabled: 

□ Client-to-client direct connections do not occur. 

□ After a file transfer request is allowed by the ProxySG, the resulting data is sent directly from one 
client to another without passing through the ProxySG: 



769 



Blue Coat Proxy SG Configuration and Management Guide 



• For MSN: The above bullet point only applies to MSN version previous to and including 6.0. 
Post-6.0 versions use a dynamic port for file transfers; therefore, port 6891 is not required for 
the ProxySG to intercept file transfers. 

• For Yahoo: The above bullet only applies to standard file transfer requests. Port 5101 must be 
enabled to allow file list requests. 



Note: All file transfers for AOL clients are handled through the default (5190) or specified client 

login port. 



To enable a default IM port or configure additional IM services, see Chapter 5: "Managing Port 
Services" on page 151. 

About HTTP Proxy Support 

SGOS 4.x supports instant messaging through PITTP proxy. IM clients can be configured to connect to 
IM services through PITTP, which allows IM activity from behind restrictive firewalls. 

The ProxySG supports PITTP proxy for Yahoo, MSN, and AOL IM clients, including application of 
policies and IM activity logging. This is accomplished by the PITTP proxy handing off IM 
communications to the IM proxy. 

Limitations 

AOL and Yahoo clients lose certain features when connected through PITTP proxy rather than 
through SOCKS or transparent connections: 

□ AOL — Direct connections, file transfers, and files sharing are not available. 

□ Yahoo — Client cannot create a chat room. 

About Instant Messaging Reflection 

IM reflection allows you to contain IM traffic within the enterprise network, which further reduces the 
risk of exposing company-confidential information through public IM networks. Normally, an IM sent 
from one buddy to another is sent to and from an IM service. With IM reflection, IM traffic between 
buddies, including chat messaging, on the same network never has to travel beyond the ProxySG. 
This includes IM users who login to two different ProxySG appliances configured in a hierarchy 
(proxy chaining). 

IM Reflection Diagrams 

The following diagrams depict how the ProxySG manages IM reflection. 

IM Reflection with Fail Open 

The following diagram demonstrates IM reflection deployment with fail open on a ProxySG that is 
configured to attempt to reflect all IM activity. IM clients 1 and 2 logged into the same ProxySG, while 
client 3 is outside the network. IM activity between clients 1 and 2 are reflected by the ProxySG; IM 
activity between clients 1 and 3 are forwarded to the IM service provider for normal delivery. 
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IM Client 1 

Do you want me to 
pick up dinner? 



IM Reflection: fail open 
Policy: 

< Proxy > 

im. reflect (yes) 



\ 



\ 



X 



\ 




Figure 17-1: IM Reflection with Fail Open 

IM Reflection With Fail Closed 

By adding a policy rule to deny IM service to clients not logged into the ProxySG, client 1 receives a 
denial of service message when trying to message client 3. 
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IM Reflection: fail closed 




Figure 17-2: IM Reflection with Fail Closed 

IM Reflection With A Hierarchy Of Proxies 

Larger enterprise networks have users logging in through different primary ProxySG appliances. IM 
reflection is still possible by using SOCKS and HTTP forwarding, policy, and a ProxySG hierarchy. 

Consider the following deployment. IM Clients 1 and 2 are located on the same main campus, but log 
into different primary ProxySG appliances, PSG 1 and PSG 2, which proxy to the intermediate 
ProxySG, PSG 3. IM Client 3 is an employee in a remote location and logs into PSG 4. PSG 5 is the 
corporate root appliance. IM Client 4 is a buddy of IM Client 2, but is not on the employee network. 
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IM Reflection: fail closed policy for PSG 5: 
Policy rule 1: 

<Proxy> 

im. reflect (yes) 

Policy rule 2: 

<Proxy> 

im . message . re flected= failed 
deny 

PSG 5 



IM Service 
Provider 



PSG 3 




IM Client 1 to 2: 


1 


IM Client 2 to 1: 


Did you finish coding 


\ 


Yes! The system runs ten 


Project X? 


times faster now! 



i 



iIM Client 4 




PSG 4 



f 



IM Client 3 to 1: 
Awesome! We'll start 
selling Project X. 



IM Client 1 to 3: 
Project X is complete. 



IM Client 2 to 4: 
I'm so happy! We 
finished Project X! 
Admin: Denial of 
service. 



IM Reflection: proxy hierarchy, fail closed policy for PSG 1-4: 

define condition "IM protocols" client .protocol= (aol-im, msn- im, yahoo- im) end 
condition "IM protocols" 



<Forward> 

condition= " IM protocols" socks_gateway (gateway_l ) socks_gateway . f ail_open (no) 

Figure 17-3: IM Reflection with SOCKS Forwarding in a Proxy Hierarchy 
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Each primary and intermediate ProxySG (PSGs 1, 2, 3, and 4) forwards IM traffic that is not reflectable 
(policy to fail open) to the next ProxySG in the chain. If the next ProxySG services the appropriate IM 
client, the message is reflected and delivered. The root ProxySG, PSG 5, has a policy to fail close. 
Therefore, all IM traffic forwarded to it that cannot be reflected, such as IM Client 2's attempt to 
contact IM Client 4, is denied access to the public IM service. 

Further policy fine-tuning can allow or disallow IM forwarding based on other triggers. For example, 
the group Corp-Market can send messages to anyone inside or outside the network, but all other 
groups are prohibited from sending messages to the outside. 

About Instant Messaging Proxy Authentication 

The ProxySG supports explicit proxy authentication if explicit SOCKS V5 proxy is specified in the IM 
client configuration. 

Because the IM protocols do not support proxy authentication natively, authentication for 
transparently redirected clients is not supported because policies requiring authentication would 
deny transparently redirected clients. 

HTTP Proxy Limitations 

The following proxy authentication limitations apply to IM clients using HTTP proxy: 

□ AOL IM — Proxy authentication is supported. 

□ MSN IM (5.0 and above) — Although the MSN IM client supports user credentials, it cannot 
respond to HTTP proxy authentication requests from the ProxySG and the MSN passport service 
login fails. You can, however, add policy to pass-through the traffic to the MSN passport . com site 
without requiring authentication. 

□ Yahoo IM — Yahoo IM clients do not have proxy authentication configuration abilities. 

Securing AOL Encryption Capability 

This section describes AOL encryption capabilities and how to manage them with ProxySG policy. 

About AOL Encryption 

AOL IM provides the option for clients to send encrypted messages through both standard messaging 
(through a service) and direct connection messaging. While this encryption benefits IM users, it 
provides a security risk for corporate network administrators implementing a communication policy 
through a proxy. Encryption-capable AOL IM buddies can enable encryption and communicate. 
Because the ProxySG cannot decrypt these communications, policy cannot be applied and sensitive 
material can be transferred between buddies without a denial of service or access logging for 
key-word matching. The ProxySG also cannot replace or append encrypted text, rendering that IM 
proxy feature useless. 

To allow unabated proxy control of IM traffic, SGOS 4.x can strip the encryption capabilities from 
AOL and Trillian IM clients. While this might appear counter-intuitive to securing communications, 
greater security and control are gained from the ability to apply policy to message content and to log 
communications. Determine the need to strip encryption based on your enterprise proxy 
requirements. 
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Note: If encryption is blocked, the service does not recognized the logged-in IM client as capable 

of encryption. If a proxied client attempts to create a chatroom with encryption on, the 
client receives a create error. This behavior is expected. 



Policy for Stripping AOL Encryption 

The policy property is only applicable to the im . method=login trigger; other properties are not 
affected. Once encryption stripping is enabled, any existing encryption capabilities and certificates are 
stripped when a client logs in, and the IM service recognizes the clients as not able to send encrypted 
messages. 

VPM 

In a Web Access Layer, select Block IM Encryption in the Action column. 

CPL 

Add the following property to the policy file: 

< Proxy > 

im. block_encryption (yes ) 

Instant Message Proxies 

This section discusses the IM proxy behavior and configurations on the ProxySG. 

Configuring Instant Message DNS Redirection 

The ProxySG can be configured as an IM proxy that performs a DNS redirection for client requests. 
This provides greater control because it prevents IM clients from making outside connections. 

The IM clients provide the DNS lookup to the IM server, which the ProxySG DNS module uses to 
connect to the IM server. To the client, the ProxySG appears to be the IM server. A virtual IP address 
used only for IM must be configured, as it is used to represent the IM server address for all IM 
protocols. 

To Configure Instant Message DNS Redirection through the Management Console 

1. Create a virtual IP address to be used for IM DNS redirection through the ProxySG. Navigate to 
Configuration>Network>Advanced>VIPs. 

2. Select Configuration>Services>IM Proxies>IM Proxy Settings. 

3. In the General Settings field, select the configured VIP from the Explicit Proxy Virtual IP drop-down 
list. 

4. In the Protocol Settings field, select an IM protocol to define: AOL, MSN, or Yahoo. Once selected, the 
appropriate host fields display below. Each field contains the default hosts used by clients to 
connect to the IM service. 

• AOL: Native IM Host, HTTP IM Host, and Direct IM Proxy Host. 
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• MSN: Native IM Host and HTTP IM Host. 

• Yahoo: Native IM Host, HTTP IM Host, HTTP Chat Host, Upload Host, and Download Host. 



Important: Only edit these hosts if the client experiences a change in its hardcoded value. 



To Configure Instant Message DNS Redirection through the CLI 

At the (config) prompt, enter the following commands: 

SGOS# (config) virtual-ip address 

SGOS# (config) im explicit-proxy-vip address 

where address is the same VIP defined with the previous command. 

SGOS# (config) im host 

where host is: 

aol-direct-proxy-host host 
aol-http-host host 
aol-native-host host 
msn-http-host host 
msn-native-host host 
yahoo-download-host host 
yahoo-http-host host 
yahoo-http-chat-host host 
yahoo-native-host host 
yahoo-upload-host host 



To view the current default or configured hosts, enter the show im command. 

Configuring Instant Message Alert Settings 

This section describes how to configure the IM proxy settings on the ProxySG. You can assign an 
administrator buddy name for each client type, and determine how exception messages are sent. 

An administrator buddy name can be a registered name user handle or a fictitious handle. The benefit 
of using a registered name is that users can send IM messages to the administrator directly to report 
any issues, and that communication can be logged for tracking and record-keeping. 
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To Configure the IM Proxy Setting through the Management Console 

1. Select Configuration>Services>IM Proxies>IM Alert Settings. 

| IM Proxy Settings ~| IM Alert Settings 




Figure 17-4: The IM Proxy Screen 

2. In the Admin buddy names field, enter the handle or handles for the administrator. 

3. In the Exception message delivery field, select the method that exception messages are delivered to 
IM users. 



Note: The ProxySG sends alert messages to the user in-band or out-of-band as specified by the 

configuration variable exceptions below. However, alert messages for those IM activities 
such as file transfer (that use direct connections), are always sent out-of-band. 



• Send exception messages in a separate window (out-of-band) — if an exception occurs, the user 
receives the message in a separate IM window. 

• Send exception messages in the existing window (in-band) — If an exception occurs, the message 
appears in the same IM window. 

If in-band is selected, the message appears to be sent by the buddy on the other end, with the 
exception that when in a chat room, the message always appears to be sent by the configured 
Admin buddy name. You can enter a prefix message that appears in the client window before 
the message. For example: “From the Company Administrator: Inappropriate IM use. Refer to 
Employee Conduct Handbook concerning Internet usage.” 



Note: Regardless of the IM exception delivery configuration, IM alert messages triggered by 

policy based on certain protocol methods are always sent out-of-band because a 
specific buddy is not associated. 



4. Click Apply. 
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To Configure the IM Proxy Setting through the CLI 

At the (config) command prompt, enter the following commands: 

SGOS# (config) im [aol | msn | yahoo] -admin-buddy admin_handle 

Specifies the handle or handles for the administrator; configure for each IM client type. 

SGOS# (config) im exceptions [in-band | out-of-band] 

Specifies the method the exception messages are delivered to IM users. If in-band is selected, 
enter the following command to specify a prefix message: 

SGOS# (config) im buddy- spoof -message text 

Configuring Instant Messaging HTTP Handoff 

IM Handoff allows the Blue Coat HTTP proxy to handle requests from supported IM protocols. If IM 
HTTP handoff is disabled, requests are passed through, and IM-specific policies are not applied. 

Handoff should be enabled (the default) if you write IM policy. 

If you want to allow a specific IM client to connect through HTTP through the ProxySG and that IM 
protocol has not been licensed, disable IM HTTP handoff to allow the traffic to be treated as plain 
HTTP traffic and to avoid an error in the licensing check done by the IM module. This might be also be 
necessary to temporarily pass through traffic from new versions of IM clients that are not yet 
supported by Blue Coat. 

To Disable Instant Messaging HTTP Handoff through the Management Console 

1. Select Configuration>Services>IM Proxies>IM Proxy Settings. 

2. Deselect Enable HTTP Handoff. 

IM Proxy Settings | IM Alert Settings 

HTTP Handoff 
r Enable HTTP Handoff 

Figure 17-5: Disabling IM HTTP Handoff 

To Disable Instant Messaging HTTP Handoff through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) im http-handoff disable 
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Configuring Instant Messenger Clients 

This section describes how to configure the IM clients to send traffic through the ProxySG. 

General Configuration 

As each IM client has different menu structures, the procedures to configure them differ. This section 
provides the generic tasks that need to be completed. 

Explicit Proxy 

Perform the following tasks on the IM client: 

1. Navigate to the Connection Preferences dialog. 

2. Select Use Proxies. 

3. Select proxy type as SOCKS V5. 

4. Enter the ProxySG IP address. 

5. Enter the SOCKS port number; the default is 1 080. 

6. Enter authentication information, if required. 

Transparent Proxy 

IM clients do not require any configuration changes for transparent proxy. An L4 switch or inline 
ProxySG routes the traffic. 

Yahoo Messenger Client Explicit Proxy Configuration Screen 

The following example configures a Yahoo Messenger client for explicit proxy. 

1. Select Login>Preferences>Connection. 

2. Click Connection. 

3. Select Use proxies. 

4. Select Enable SOCKS proxy; select Ver 5. 

5. Enter the server name. 

6. Enter the port number (the default is 1 080). 

7. If authentication is required on the ProxySG, enter the authentication user name and password. 
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Figure 17-6: Yahoo IM Client Explicit Proxy Configuration 
Notes 

If Yahoo Messenger is configured for explicit proxy (SOCKS) through the ProxySG, the IM voice chat 
feature is disabled. Any client attempting a voice chat with a client behind the ProxySG firewall 
receives an error message. The voice data stream is carried by default on port 5001; therefore, you can 
create and open this port and configure Yahoo IM to use transparent proxy. However, the ProxySG 
only supports the voice data in pass-through mode. 

AOL Messenger Client Explicit Proxy Configuration Screen 

The following example configures an AOL Messenger client for explicit proxy. 

1. Select My AIM>Edit Options>Edit Preferences>Sign On/Off. 

2. Click Connection. 

3. Select Connect using proxy. 

4. Select SOCKS 5. 

5. Enter the server name. 

6. Enter the port number (the default is 1 080). 

7. If authentication is required on the ProxySG, enter the authentication user name and password. 
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Connection Preferences 



-Server — 

Host | login. oscar. aol.com 
Port [5190 



*j 

Auto Configure. .. | 
Reset 



~W Connect using proxy 
r Proxy Server 
Host: |10.1.1.1 
Port: [1080 



r Authentication 



Username: | 
Password: [" 



Some HTTPS servers may disconnect you from A0L Instant Messenger 
without warning. 





r Protocol 




r SOCKS 4 




SOCKS 5 




r HTTPS 




C HTTP 



JKj Cancel 

Figure 17-7: AOL IM Client Explicit Proxy Configuration 



MSN Messenger Client Explicit Proxy Configuration Screen 

The following example configures an MSN Messenger client for explicit proxy. 

1. Select Tools>Options. 

2. Click Connection. 

3. Select I use a proxy server. 

4. Select SOCKS Version 5. 

5. Enter the server name. 

6. Enter the port number (the default is 1 080). 

7. If authentication is required on the ProxySG, enter the authentication user name and password. 
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Figure 17-8: MSN IM Client Explicit Proxy Configuration 

VPM Examples 

Once the IM clients are configured to send traffic through the ProxySG, you can control and limit IM 
activity The Visual Policy Manager (VPM) allows you to create rules that control and track IM 
communications, including IM activities based on users and groups, IM handle, chat room handle, file 
name, and other triggers. 

To learn about the VPM, see Chapter 14: "The Visual Policy Manager" on page 567. 

Example 1 : File Transfer 

The following example demonstrates an IM rule created with the VPM that IM handle Nigell can 
perform a file transfer at any time, but the file must be between 1 and 5 MB in size, and the handle, the 
file path, and file size are logged: 

1. In the VPM, select Policy>Add Web Access Layer; name it IM_FileTransfer. 

2. Right-click the Source field; select Set. The Set Source Object dialog appears. 

3. Click New; select IM User. The Add IM User Object dialog appears. 

4. In the IM User field, enter Nigell; click OK in each dialog. 

5. Right-click the Service field; select Set. The Set Service Object dialog appears. 

6. Click New; select IM File Transfer. The Add IM File Transfer dialog appears. 

7. Select Size and enter a range 1 and 5; select MBytes from the drop-down list; click OK in each 
dialog. 
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8. Right-click the Track field; select Set. The Add Track Object dialog appears. 

9. Click New; select Event Log. The Add Event Log Object dialog appears. 

10. From the Substitution Variables list, select x-im-buddy-name and click insert. Repeat for x-im-file-path 
and x-im-file-size. Click OK in each dialog. 

11. Click Install Policy. 

Example 2: Send an IM Alert Message 

The following example demonstrates a rule created with the VPM that informs all IM users when they 
login that their IM activity is tracked and logged. 

1. In the VPM, select Policy>Add Web Access Layer; name it IM_NotifyMessage. 

2. Right-click the Service field; select Set. The Set Service Object dialog appears. 

3. Click New; select Protocol Methods. The Add Methods Object dialog appears. 

4. From the Protocol drop-down list, select Instant Messaging. 

5. Click Login/Logout; LOGIN; click OK to close the dialog; click OK to insert the object in the rule. 

6. Right-click the Action field; select Set. The Set Action Object dialog appears. 

7. Click New; select Send IM Alert. The Add Send IM Alert Object dialog appears. 

8. In the Alert Text field, enter a message that appears to users. For example. Notice: Your Instant 
Messaging message activity is tracked and logged. 

9. Click OK to close the dialog; click OK to insert the object in the rule. 

10. Click Install Policy. 

Statistics 

The IM statistics allow you to track IM connections, file transfers, and messages that are currently in 
use and in total, or have been allowed and denied. The information can be displayed for each IM client 
type or combined. 

For information about viewing IM statistics, see "IM History Statistics" on page 986. 

Related Material 

Refer to the following Blue Coat documentation for related IM information: 

□ Chapter 14: "The Visual Policy Manager" on page 567 

□ Blue Coat ProxySG Content Policy Language Guide 
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The ProxySG allows the use of content filtering to control the type of content retrieved by the ProxySG 
and to filter requests made by clients. You can use a local content-filtering database and/ or 
content-filtering policy to reduce the infinite number of URLs to a small number of categories and 
then manage those categories. Categories can be used anywhere you would use a URL-based trigger. 

You can also combine the ProxySG local database and policies with a content-filtering vendor to 
provide a cohesive approach to managing access to the Web. 

This chapter contains the following topics: 

□ "Overview" on page 786 

□ "Selecting Category Providers" on page 787 

□ "Configuring a Local Database" on page 791 

O "Configuring Blue Coat Web Filter" on page 795 
n "Configuring i-FILTER" on page 804 

□ "Configuring InterSafe" on page 807 

□ "Configuring IWF" on page 810 

□ "Configuring Optenet" on page 812 

n "Configuring Proventia Web Filter" on page 815 

□ "Configuring SmartFilter" on page 818 

□ "Configuring SurfControl" on page 821 

□ "Configuring Websense" on page 824 

□ "Configuring Webwasher URL Filter" on page 828 

□ "How to Apply Policy to Categorized URLs” on page 833 

□ "Using Content-Filtering Vendors with ProxySG Policies" on page 836 
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Overview 

Content filtering allows you to categorize Web sites (such as sports and gambling). After the Web sites 
and content are categorized, access to that content can be controlled through policy. 

The ProxySG content filtering feature (which requires a license — see Chapter 2: "Licensing" on page 
47) allows you to integrate subscription-based filtering lists that are automatically updated and 
categorized as the Web changes. 

Content filtering allows you to block sites based on what you believe to be in them. You can either 
filter URLs yourself, allowing or denying permission to them using your own local content-filtering 
database, you can use the Blue Coat Web Filter, or you can use a third-party content-filtering vendor 
to provide the categories and assign the categories to URLs. 

Categories and their meanings are defined by the specific category providers. For third-party 
databases, the most up-to-date information on how categories are assigned to URLs can be obtained 
from the provider's Web site. You can request that specific URLs be reviewed for correct 
categorization, if your content-filtering provider supports this. 



About the Internet Watch Foundation 

The Internet Watch Foundation (IWF) is a non-profit organization that provides to enterprises lists of 
known child pornography URLs in a single category called IWF-Restricted. Because of the sole 
purpose of this provider, the ProxySG supports the IWF option along with any other vendor you 
select. During content filtering configuration, you can select this option; then create policy to block 
this category. 

Configuration Sections 

Examples in this document are believed to be correct at the time of publication, but could be affected 
by subsequent changes in third-party databases. 

After the content is categorized, you can control access to the categories (using policy) by username, 
department, time of day, and other criteria. 

To use a third-party vendor for content filtering, contact the vendor for license and authorization 
information. Continue with the appropriate section to configure the properties. 

□ "Selecting Category Providers" on page 787 

□ "Configuring a Local Database" on page 791 

□ "Configuring Blue Coat Web Filter" on page 795 

□ "Configuring InterSafe" on page 807 

□ "Configuring Optenet" on page 812 

□ "Configuring SmartFilter" on page 818 

□ "Configuring SurfControl" on page 821 

□ "Configuring Websense" on page 824 

□ "Configuring Webwasher URL Filter" on page 828 
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To use policy to create and manage categories, see "How to Apply Policy to Categorized URLs” on 
page 833. To use policy to refine third-party vendor content filtering, see "Using Content-Filtering 
Vendors with ProxySG Policies" on page 836. 

Selecting Category Providers 

You can select a local database. Blue Coat Web Filter (BCWF), or a third-party vendor database for 
content filtering, view the filtering categories available, and test a URL through either the 
Management Console or the CLI. 

To Select a Local Database, Blue Coat Web Filter, or Third-Party Vendor Database through the 
Management Console 

1. Select Configuration>Content Filtering>General; the General tab displays. 

General 



„ .J_„_ 


Provider Enable Lookup mode 

Local Database: □ ©Always Q Uncategorized 

Internet Watch Foundation: Q ©Always O Uncategorized 

Blue Coat Web Filter: □ ©Always O Uncategorized 

3rd-party database: None v| ©Always O Uncateqorized 






| | Enable Category Review Message in Exceptions 






( view Categories view available categories 

|| Test | 





Figure 18-1: Content Filtering, General Tab 



2. Select the database you want to use. 

a. To use a local database for content filtering, select Use Local Database. 

b. To use Blue Coat Web Filter for content filtering, select Use Blue Coat Web Filter. 



Note: If you select Blue Coat Web Filter, a small database that contains the category list is 

downloaded immediately, allowing immediate policy creation. 

No username or password is required during the trial period (60 days). To download 
the database on demand or on a schedule, or to try out dynamic categorization, you 
must configure the BCWF service. 
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c. If you are using a licensed third-party vendor (either instead of or in addition to a local 
database or the Blue Coat Web Filter service), select the vendor from the Use 3rd party 
database drop-down list. Select None to stop using a vendor. 

d. Select Use Internet Watch Foundation to add the IWF-Restricted (known child pornography 
URLs) category. For a description of IWF, see "About the Internet Watch Foundation" on 
page 786. 

3. (Optional) Select the Lookup Mode to use. The default is Always, which indicates that any installed 
database should be consulted on every categorization attempt. Uncategorized indicates that 
installed data should be skipped if the URL already has categories assigned. 

4. (Optional) If you are using a provider that supports it, you can select the Enable Category Review 
Message in Exceptions. In conjunction with two substitutions — 

$ (exception. category_review_url) and $ (exception. category_review_message) — you 
can request that specific URLs be reviewed for correct categorization. 

If you enable the Category Review Message, the two substitutions are automatically appended to 
the help element of all exception definitions. For information on using the $ (exception. help) 
element, see "User-Defined Exceptions" on page 716. 



Note: The substitution values are empty if the selected content filter provider does not support 

review messages, or if the provider was not consulted for categorization, or if the 
categorization process failed due to an error. 

5. Click Apply. 

6. (Optional) To see all categories available for use in policy, click View Categories. Categories are not 
displayed for a vendor or local database if no database has been downloaded. 

7. To see what categories a Web site is assigned by your current configuration, enter the URL into 
the URL field and click Test. 

To Select a Content-Filter Provider through the CLI 

1. At the (config) command prompt, enter the following command to enter content-filter mode: 
SGOS# (config) content- filter 

2. To select Blue Coat Web Filter, a local database, IWF, or a third-party provider, enter the 
following commands: 

SGOS# (config content-filter) provider bluecoat {enable | disable | 
lookup-mode (always | uncategorized}} 

SGOS# (config content-filter) provider local {enable | disable | lookup-mode 
(always | uncategorized} 

SGOS# (config content-filter) provider iwf {enable | disable | lookup-mode 
(always | uncategorized}} 

SGOS# (config content-filter) provider 3rd-party {i-filter | intersafe | 
optenet | proventia | smartfilter | surfcontrol | websense | webwasher} 

-or- 

SGOS# (config content-filter) provider 3rd-party none | lookup-mode (always | 
uncategorized} 
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where: 



bluecoat 


enable | disable | lookup-mode 
{always | uncategorized} 


Enables or disables Blue Coat Web Filter. 
Use lookup mode to specify whether 
every URL should be categorized by the 
downloaded filter. 


local 


enable | disable | lookup-mode 
{always | uncategorized} 


Enables or disables a Local database. Use 
lookup mode to specify whether every 
URL should be categorized by the 
downloaded filter. 


iwf 


enable | disable | lookup-mode 
{always | uncategorized} 


Enables or disables IWF. Use lookup 
mode to specify whether every URL 
should be categorized by the downloaded 
filter. 


3rd-party 


i-filter | intersafe | optenet 
| proventia | smartfilter | 
surfcontrol | websense | 
webwasher 


Specifies a 3rd-party provider. 


none | lookup-mode {always | 
uncategorized} 


Specifies no 3rd-party provider or you 
can use lookup mode to specify whether 
every URL should be categorized by the 
downloaded filter. 



3. (Optional) You can request that specific URLs be reviewed for correct categorization. 

SGOS# (config content-filter) review-message | no review-message 

If you enable review-message, two substitutions — $ (exception. category_review_url) and 
$ (exception. category_review_message) — are automatically appended to the help element of 
all exception definitions. For information on using the $ (exception . help) element, see 
"User-Defined Exceptions" on page 716. 



Note: The substitution values are empty if the selected content filter provider does not 

support review messages, or if the provider was not consulted for categorization, or if 
the categorization process failed due to an error. 



4. (Optional) To identify the categories assigned by the current configuration to a particular URL, 
enter the following command: 

SGOS# (config content-filter) test-url url 

where url specifies the URL for which you want to identify categories. 

5. (Optional) To view all available categories, which might include those created by policy, a local 
database if enabled, a selected vendor, and the system, enter the following command: 

SGOS# (config content-filter) categories 
Categories defined by Policy: 

Sports URLs 
Entertainment 
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Categories defined by Local: 
catl 
cat2 
cat3 
cat4 



Categories defined by SurfControl: 
Web-based Email 
Motor Vehicles 



ftp://10.25 . 36 .47/list- 1000000 -cat .t 
anonymous 
Enabled 
0 

sun, mon, tue, wed, thu, fri, sat 



Chat 

(Long list truncated) 

Categories defined by System: 
none 

unavailable 
unlicensed 

6. (Optional) View the content-filtering configuration. 

SGOS# (config content-filter) view 
Provider Local 

Status : Ready 

Download URL: 

Download Username: 

Automatic download: 

Download time of day (UTC) : 

Download on: 

Download log: 

Local database download at: 12 Jan 2006 00:19:48 UTC 
Downloading from ftp://10.25.36.47/list-1000000-cat.txt 
Download size: 16274465 

Database date: 12 Jan 2006 00:22:04 UTC 
Total URL patterns: 1000000 
Total categories: 10 

Provider : 

Status : 

Download License key: 

Download Server: 

Email contact: 

Automatic download: 

Download time of day (UTC) : 

Download on: 

Use regular expression filters: 

Config Server: 

Config Server listening port: 

Download log: 

Websense download at: 12 Jan 2006 22:11:37 UTC 
Downloading from download.websense.com 
Download size: 63642227 



Websense 

Ready 

TUVW67XYZ89ABC0 
download . websense . com 



Enabled 

0 

sun, mon, 
No 

Disabled 

15870 



tue, wed, thu, fri, sat 
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Database version: 71617 

Database date: 2004-01-28 

License expires: 12 Nov 2006 08:00:00 UTC 
License max users: 25 

Licenses in use: 1 

Configuring a Local Database 

You can create your own local database file and download it to the ProxySG. This file is created in the 
same way that policy files are created, except that only define category statements are allowed in the 
local database. Refer to the Blue Coat ProxySG Content Policy Language Guide for information on define 
category statements, or see "Defining Custom Categories in Policy" on page 837. 



Note: You might find it convenient to put your local database on the same server as any policy 

files you are using. 



Two main reasons to use a local database instead of a policy file for defining categories are: 

□ A local database is more efficient than policy if you have a large number of URLs. 

□ A local database separates administration of categories from policy. This separation is useful for 
three reasons: 

• It allows different individuals or groups to be responsible for administrating the local 
database and policy. 

• It keeps the policy file from getting cluttered. 

• It allows the local database to share categories across multiple boxes that have different 
policy. 

However, some restrictions apply to a local database that do not apply to policy definitions: 

□ No more than 200 separate categories are allowed. 

□ Category names must be 32 characters or less. 

□ A given URL pattern can appear in no more than four category definitions. 

You can use any combination of the local database, policy files, or the VPM to manage your category 
definitions. See "How to Apply Policy to Categorized URLs" on page 833 for more information. You 
can also use both a local database and a third-party vendor for your content filtering needs. 

Use the ProxySG Management Console or the CLI to configure local database content filtering and to 
schedule automatic downloads. For information about scheduling automatic downloads, see 
"Scheduling Automatic Downloads for a Local Database" on page 794. 
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To Configure Local Database Content Filtering through the Management Console 

1. Select Configuration>Content Filtering>Local Database; the Local Database tab displays. 

Local Database | Automatic Download 




( View Database Source ] 

Figure 18-2: Local Database Configuration Tab 

2. (Optional) If you need a password to access the download site, click Change Password, enter the 
password in the Change Password dialog, and click OK. 

3. Enter the database download URL in the URL field. 

4. (Optional) To display the currently installed text file, click View Database Source; close the display 
when you are finished. 

5. Click Apply. 

6. (Optional) To download the local database immediately, complete the following steps. 



Note: You can return here at any time to download a database on demand (remember that the 

automatic download feature, if configured, keeps you up-to-date — see "Scheduling 
Automatic Downloads for a Local Database" on page 794). 

Ordinarily, the ProxySG checks if the database has changed before initiating a download. 
If the database is up to date, then no download is necessary and none is performed. 



a. Click Download Now. 

The Local Installation status dialog box displays with the message Local download in progress. 
When the operation is complete, the dialog changes to indicate installation status. 



< Installation status 



Local Installation 

The new Local filter was successfully downloaded and installed. 
Use the "Results" button to view full details 



I OK l| Results | 

Figure 18-3: Local Database Successfully Downloaded 
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b. Click Results to see the completion message: 

Download log: 

Local database download at: 12 Oct 2006 19:29:39 UTC 

Downloading from ftp://10.25.36.47/list-1000000-cat.txt 

Download size: 16274465 

Database date: 12 Oct 2006 19:31:58 UTC 

Total URL patterns: 1000000 

Total categories: 10 



To Configure Local Database Content Filtering through the CLI 

The following commands allow you to enter the username, specify the URL from which the database 
is to be downloaded, and do an immediate download of the local database. If required, you can also 
clear the database and all associated files. 



1 . 



At the (config) command prompt, enter the following commands: 

SGOS# (config) content-filter 

SGOS# (config content-filter) local 

SGOS# (config local) download username username 
SGOS# (config local) download password password 



SGOS# (config local) 
SGOS# (config local) 
SGOS# (config local) 



download encrypted-password encrypted_password 

download url url 

clear 



where: 



clear 




Clears the database from the system. 


download 

username 


username 


Identifies the username needed to access the 
download site, if any. 


download 

encrypted- 

password 


encrypted-password 


Allows you to take a password previously 
encrypted by the ProxySG and cut and paste the 
encrypted password on the same appliance (or 
another appliance if it shares the same 
password-display keyring). 

The primary use of the encrypted-password 
command is to allow the ProxySG to reload a 
password that it encrypted. 


download 

password 


password 


Identifies the password needed to access the 
download site, if any. 


download url 


url 


The local URL. 



2. (Optional) To download the database now, enter one of the following commands: 

SGOS# (config local) download get-now 

where download get -now Initiates an immediate database download. If the database is 
already up-to-date, no download is initiated. 

3. (Optional) To view the local database source file, enter the following command: 

SGOS# (config local) source 
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4. 



(Optional) To view the configuration, enter the following command: 

SGOS# (config local) view 



Ready- 

ftp: //10.25.36.47/list- 1000000-cat.txt 
userl 
Enabled 
0 

sun, raon, tue, wed, thu, fri, sat 



Status : 

Download URL: 

Download Username: 

Automatic download: 

Download time of day (UTC) : 

Download on: 

Download log: 

Local database download at: 08 Jul 2006 18:40:11 UTC 
Downloading from ftp://10.25.36.47/list-1000000-cat.txt 
Download size: 612 

Database date: 08 Jul 2006 18:38:57 UTC 
Total URL patterns : 8 
Total categories: 5 



Scheduling Automatic Downloads for a Local Database 



Note: By default, the automatic download setting is enabled (for every day at midnight, UTC) 

and does not need to be configured unless you want to change the schedule or disable 
auto-download. 

To download the local database without creating a schedule, see "Configuring a Local 
Database" on page 791. 



The Automatic Download tab allows you to set the times the local database is downloaded. You can 
specify an automatic download on the day and time. Because sites become stale quickly. Blue Coat 
recommends downloading on an automatic schedule frequently. 

When the database is downloaded, a log is available that includes the information about how the 
database was updated, but in a more detailed form. You can view the download log through the 
Management Console (Statistics>Advanced>Content Filter Service) or the CLI (SGOS#(config) show 
content-filter status). 



To Set Local Database Automatic Download Times through the Management Console 

1. Select Configuration>Content Filtering>Local Database>Automatic Download; the Automatic Download 
tab displays. 



Local Database 

Automatic download: 



Automatic Download 



0 Download new filter at midnight 



UTC on the following days: 



0 Sunday 
0 Wednesday 



0 Monday 
0 Thursday 



0 T uesday 
0 Friday 



0 Saturday 



Figure 18-4: Local Database Automatic Download Tab 

2. To set up a schedule for local database downloads, select Download new filter at and select the time 
of day from the drop-down list. The default is Midnight. 
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3. All days are selected by default. Deselect days as needed. 

4. Click Apply when finished. 



To Set Local Database Automatic Download Times through the CLI 



1 . 



At the (conf ig) command prompt, enter the following commands to enable or disable automatic 
downloading of the local database. 

SGOS# (config) content-filter 

SGOS# (config content-filter) local 
SGOS# (config local) download auto 



-or- 

SGOS# (config local) no download auto 



2. At the (config local) command prompt, enter the following command to select the day(s) to 
automatically download the local database. 

SGOS# (config local) download day-of-week {all | none | sun | mon | tue | wed 
| thu | fri | sat} 

-or- 

SGOS# (config local) no download day-of-week {sun | mon | tue | wed | thu | fri 
| sat } 



where all selects all days of the week, and none clears all days of the week from the schedule. 

All days are selected by default; to deselect days, enter none and enter specific days. You can 
only select one day each time, but it is appended to the list. You can also use the no download 
day-of-week command to clear specific days from the schedule. 

3. Enter the following command to specify the hour (UTC) of the selected days during which the 
download should be performed. 

SGOS# (config local) download time-of-day 0-23 



4. (Optional) To download the local database now, enter the following command: 
SGOS# (config local) download get-now 



Downloading the database now does not affect the automatic database download schedule. 



Configuring Blue Coat Web Filter 

Blue Coat Web Filter (BCWF) is a highly effective content filter that can quickly learn and adapt to the 
working set of its users. Also, BCWF provides a network service that can dynamically examine and 
categorize Web pages as they are requested. This dynamic real-time categorization enhances both the 
accuracy and freshness of the BCWF filtering solution. 



Note: If you enable Use Blue Coat Web Filter on the Configuration>Content Filtering>General page, a 

small database that contains the category list downloads immediately, while the full 
BCWF database downloads in the background. All filtering is performed by the BCWF 
dynamic categorization service while the full database downloads. 

No username or password is required during the trial period (60 days). 
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For information on configuring dynamic categorization, see "Configuring Dynamic Categorization for 
Blue Coat Web Filter" on page 800. 

Use the ProxySG Management Console or the CLI to configure BCWF. 

To Configure Blue Coat Web Filter through the Management Console 

1. Select Configuration>Content Filtering>Blue Coat Web Filter; the Blue Coat Web Filter tab displays. 

Blue Coat Web Filter | Automatic Download | Dynamic Categorization 




Figure 18-5: Blue Coat Web Filter Configuration Tab 

2. When you subscribed to the BCWF Service, you received a username and password for access to 
download updates. Enter your username into the Username field and click the Change Password 
button to enter or change your password. (If you are in the trial period, no username or password 
is required.) 

3. The default database download location is displayed in the URL field. If you have been instructed 
to use a different URL, enter it here. You can restore the default at any time by clicking Set to 
default. 

4. (Optional) To download the Blue Coat Web Filter database immediately, complete the following 
steps. 



Note: You can return here at any time to download a database on demand (remember that 

the automatic download feature, if configured, keeps you up to date — see 
"Scheduling Automatic Downloads for Blue Coat Web Filter" on page 799). 

Ordinarily, the ProxySG checks to see if the database has changed before initiating a 
download. If the database is up to date, no download is necessary and none is 
performed. If an incremental update is available on the server, then it is downloaded 
(an incremental update contains only the changes between the current installed 
version and the latest published version of the database, and is much smaller than a 
full copy of the database). 



a. Click Download Now. 

The Blue Coat Web Filter Installation status dialog box displays with the message Blue Coat 
Web Filter download in progress. 

When the operation is complete, the dialog changes to indicate installation status. 
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# Installation status 



^iSJxJ 



Blue Coat Installation 

The new Blue Coatfilterwas successfully downloaded and installed. 
Use the "Results" button to view full details 



b. 



OK | Results | 

Figure 1 8-6: Blue Coat Web Filter Database Successfully Downloaded 
Click Results to see the Blue Coat Web Filter download log: 



Download log: 

Blue Coat download at: Thu, 10 Feb 2005 00:04:06 UTC 

Downloading from https : / /list . bluecoat . com/bcwf /activity/download/bcwf . db 
Requesting differential update 
Differential update applied successfully 
Download size: 84103448 

Database date: Wed, 09 Feb 2005 08:11:51 UTC 

Database expires: Fri, 11 Mar 2005 08:11:51 UTC 

Database version: 2005040 



To Configure Blue Coat Web Filter Content Filtering through the CLI 

The following commands allow you to enter the Blue Coat Web Filter username and password and 
define the default URL and the default URL location. 



1. At the (config) command prompt, enter the following commands: 

SGOS# (config) content- filter 

SGOS# (config content-filter) bluecoat 
SGOS# (config bluecoat) download username username 
SGOS# (config bluecoat) download password password 
-or- 

SGOS# (config bluecoat) download encrypted-password encrypted-password 
SGOS# (config bluecoat) download url {default | url} 

where: 



download username 



username 



Specifies the username assigned to you for 
database download. If you are in the trial period, 
no username is required. 
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download 
encrypted- 
pas sword 


encrypt ed_password 


Allows you to take a password previously 
encrypted by the ProxySG and cut and paste the 
encrypted password on the same appliance (or 
another appliance if it shares the same 
password-display keyring). 

The primary use of the encrypted-password 
command is to allow the ProxySG to reload a 
password that it encrypted. 

If you are in the trial period, no password is 
required. 


download password 


password 


Specifies the password assigned to you for 
database download. If you are in the trial period, 
no password is required. 


download url 


default 


Specifies the use of the default download URL. 


url 


The URL is the Blue Coat Web Filter URL. You 
can change it if directed to do so. 



2. (Optional) To download the database now, enter one of the following commands: 

SGOS# (config bluecoat) download get-now 

where download get -now initiates an immediate database download. An incremental update is 
requested. 

3. (Optional) View the configuration. 

SGOS# (config bluecoat) view 

Status: Ready 

Download URL : https://list. bluecoat . com/bcwf / activity/ download/bcwf . db 
Download Username: 

Automatic download: Enabled 

Download time of day (UTC) : 0 

Download on: sun, mon, tue, wed, thu, fri, sat 

Download log: 

Download log: 

Blue Coat download at: Thu, 10 Feb 2005 00:04:06 UTC 
Downloading from 

https://list. bluecoat . com/bcwf / activity /download/bcwf . db 
Requesting differential update 
Differential update applied successfully 



Download size: 
Database date : 
Database expires : 
Database version: 



84103448 

Wed, 09 Feb 2005 08:11:51 UTC 
Fri, 11 Mar 2005 08:11:51 UTC 
2005040 
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Scheduling Automatic Downloads for Blue Coat Web Filter 



Note: By default, the automatic download setting is enabled (for every day at midnight, UTC) 

and does not need to be configured unless you want to change the schedule or disable 
auto-download. 

To download the Blue Coat Web Filter database without creating a schedule, see 
"Configuring Blue Coat Web Filter" on page 795. 



The Automatic Download tab allows you to set the times at which the Blue Coat Web Filter database is 
downloaded. You can specify an automatic download on the day and time you prefer. Because sites 
become stale quickly. Blue Coat recommends downloading on an automatic schedule frequently. 

When the database is downloaded, a log is available that includes the information about how the 
database was updated, but in a more detailed form. You can view the download log through the 
Management Console (Statistics>Advanced>Content Filter Service) or the CLI (SGOS# (conf ig) show 
content-filter status). 



To Set Blue Coat Web Filter Automatic Download Times through the Management Console 

1. Select Configuration>Content Filtering>Blue Coat Web Filter>Automatic Download; the Automatic 
Download tab displays. 



Blue Coat Web Filter Automatic Download | Dynamic Categorization 

r Automatic download: 



0 Download new filter at 



midnight 



UTC on the following days: 



0 Sunday 0 Monday 0 Tuesday 

0 Wednesday 0 Thursday 0 Friday 0 Saturday 



Figure 18-7: Blue Coat Web Filter Automatic Download Tab 



2. To set up a schedule for Blue Coat Web Filter database downloads, select Download new filter at and 
select the time of day from the drop-down list. The default is Midnight. 

3. All days are selected by default. Clear checkboxes as needed. 

4. Click Apply. 



To Set Blue Coat Web Filter Automatic Download Times through the CLI 



1 . 



At the (conf ig) command prompt, enter the following commands to enable or disable automatic 
downloading of the Blue Coat Web Filter database. 



SGOS# (conf ig) 
SGOS# (config 

SGOS# (config 
-or- 



content- filter 

content-filter) bluecoat 
bluecoat) download auto 



SGOS# (config bluecoat) no download auto 



2. At the (config bluecoat) command prompt, enter the following commands to select or deselect 
the day(s) to automatically download the local database. 
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SGOS# (config bluecoat) download day-of-week {all | none | sun | mon | tue | 
wed | thu | fri | sat} 

-or- 

SGOS# (config bluecoat) no download day-of-week {sun | mon | tue | wed | thu | 
fri | sat} 

where all selects all days of the week, and none clears all days of the week from the schedule. 

3. All days are selected by default; to deselect days, enter none and enter specific days. You can only 
select one day each time, but it is appended to the list. You can also use the no download 
day-of -week command to clear specific days from the schedule. 

4. Enter the following command to specify the hour (UTC) of the selected days during which the 
download should be performed. 

SGOS# (config bluecoat) download time-of-day 0-23 

5. (Optional) To download the Blue Coat Web Filter database now, enter the following command: 
SGOS# (config bluecoat) download get-now 

Downloading the database now does not affect the automatic database download schedule. 

Configuring Dynamic Categorization for Blue Coat Web Filter 

Dynamic Categorization provides real-time analyzing and content categorization of requested Web 
pages. 

About Dynamic Categorization 

Administrators might need to process certain URL requests in real time while other requests can be 
done in the background. Some requests might avoid dynamic categorization entirely as circumstances 
dictate. Therefore, the choice of real-time, background mode, or no dynamic categorization for each 
URL categorization can be made on a per-transaction basis using Blue Coat policy. The configuration 
establishes a default mode; Blue Coat policy can override that default. For more information, see 
Chapter 14: "The Visual Policy Manager" on page 567 or refer to the Blue Coat ProxySG Content Policy 
Language Guide. 



Note: The dynamic service is consulted only when the installed BCWF database does not 

contain complete categorization for an object. This dispatch mechanism is independent of 
results from other categorization services. 

Dynamic analysis of content is performed on a remote network service, and not locally on 
the ProxySG. If the category returned by this service is blocked by policy, the offending 
material never enters the network in any form. 



Dynamic categorization has two types of cost: 

□ Bandwidth: Represents the round trip request /response from the ProxySG to the service. Because 
the dynamic categorization protocol is compact, this cost is minimal. 

□ Latency: Represents the time spent waiting for the dynamic categorization service to provide a 
result. 
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These costs are only incurred when a URL cannot be categorized by a database lookup on the 
ProxySG. SGOS 4.x offers three modes of operation to compensate for some of this cost: 

□ Categorize dynamically in real-time (default). Real-time mode incurs both bandwidth and latency 
costs. The advantage of real-time mode dynamic categorization is that Blue Coat policy has access 
to the results of dynamic categorization, which means that policy decisions are made immediately 
upon receiving all available information. 

□ Categorize dynamically in the background. Background mode incurs only the bandwidth cost. In 
background mode after a call is made to the dynamic categorization service, the URL request 
immediately proceeds without waiting for the external service to respond. The system category 
pending is assigned to the request, indicating that the policy was evaluated with potentially 
incomplete category information. 

After it is received, the results of dynamic categorization are entered into a categorization cache 
(as are the results of real-time requests). This cache ensures that any subsequent requests for the 
same or similar URLs can be categorized quickly, without needing to query the external service 
again. 

□ Do not categorize dynamically. Dynamic categorization is not done (unless explicitly requested by 
policy). This mode is distinct from disabling the service. When Do not categorize dynamically is set as 
the default, dynamic categorization (in either real time or background mode) can be explicitly 
invoked by policy. When the service is disabled, no dynamic categorization is done, regardless of 
policy, and the ProxySG does not make any contact with the dynamic categorization service. 

About Proxy Chaining Support for BCWF Dynamic Categorization 

The ProxySG allows you to forward BCWF dynamic categorization requests through upstream 
proxies and SOCKS gateways, which eliminates the requirement for the ProxySG to have direct 
connection to back-end servers. 

Forwarding Hosts and Groups 

You can specify the alias of a forwarding host or group that has already been defined. The specified 
host and each member of a forwarding group must: 

□ Have an HTTP port configured, as that port is used for the connection. If this is not true, all 
attempts to connect fail. 

□ Have been defined as a proxy, and not as a server. An attempt to configure proxy chaining using a 
server results in an error. 

Connections fail if you remove a host's HTTP port or switch it to a server after you have configured 
the host to be in the proxy chain. Furthermore, if a forwarding host is configured to be in the proxy 
chain, it cannot be deleted from the forwarding configuration until it is removed from the chain; a 
policy warning message displays if you attempt to do so. Any load balancing configured for the 
forwarding target is obeyed, but host affinity has no effect. 
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SOCKS Gateways 

The ProxySG connects using the first healthy IP address it detects. Connections for SOCKS versions 4 
and 5 are supported. As is consistent with basic ProxySG forwarding functionality, if both a 
forwarding host or group alias and a SOCKS gateway are specified in the proxy chain, the ProxySG 
attempts the connection through the SOCKS gateway to the forwarding target. Furthermore, if a 
SOCKS gateway is configured to be in the chain, it cannot be deleted until it is removed from the 
chain (a policy warning displays). 

Configuring BCWF Dynamic Categorization 

The Dynamic Categorization tab allows you to enable or disable dynamic categorization and its 
various forms of behavior on the ProxySG. By default, dynamic categorization is enabled. 

To Configure Dynamic Categorization through the Management Console 

1. Select Configuration>Content Filtering>Blue Coat>Dynamic Categorization; the Dynamic Categorization 
tab displays. 

Blue Coat Web Filter | Automatic Download | Dynamic Categorization 
[u*1 Enable Dynamic Categorization 

- Dynamic Categorization settings 

Default dynamic categorization mode: 

O Do not categorize dynamically 
O Categorize dynamically in the background 
0 Categorize dynamically in real-time 

Forwarding target: | n0 ne v 

SOCKS gateway target: jnone V | 

Figure 18-8: Blue Coat Web Filter Dynamic Categorization 

Dynamic Categorization is enabled by default. To disable it, clear the checkbox. If dynamic 
categorization is disabled, then the ProxySG does not contact the dynamic categorization service, 
even when no category is found for a URL in the database, and any dynamic categorization 
properties specified in policy are ignored. If dynamic categorization is enabled, it is only invoked 
while BCWF is in use 

2. To change the Dynamic Categorization Settings, select one of the following: 

• Do not categorize dynamically. The loaded database is consulted for category information. URLs 
not found in the database show up as category none. 

• Categorize dynamically in the background. Objects not categorized by the database are 
dynamically categorized when time permits. 

• Categorize dynamically in real-time, the default. Objects not categorized by the database are 
dynamically categorized. 

3. (Optional) Select a forwarding host or group or SOCKS gateway from the drop-down lists. A host 
group must be comprised of proxies. After DRTR is configured to go through a host or group or 
SOCKS gateway, those targets cannot be deleted until they are deleted from the DRTR 
configuration. 
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4. Click Apply. 

To Configure Dynamic Categorization through the CLI 

The following commands allow you to analyze and manage requested Web pages in real time. You can 
also configure dynamic categorization settings and specify behavior when doing dynamic 
categorization. 

At the (config) command prompt, enter the following commands: 

SGOS# (config) content- filter 

SGOS# (config content-filter) bluecoat 

SGOS# (config bluecoat) service {enable | disable} 

SGOS# (config bluecoat) service forward host-or-group-alias 
SGOS# (config bluecoat) service socks -gateway gateway-alias 
SGOS# (config bluecoat) service mode {background | realtime | none} 



where: 



service 


enable | disable 


Enable or disable dynamic categorization. Dynamic 
categorization is enabled by default. 


service 


mode {background | 
realtime | none} 


Perform dynamic categorization one of three ways: 

• background: Objects not categorized by the 
database are dynamically categorized when time 
permits. 

• realtime: The default. Objects not categorized by 
the database are dynamically categorized. 

• none: The loaded database is consulted for 
category information. URLs not in the database 
show up as category none. 


service 


forward 

host-or-group-alias 
1 socks-gateway 
gateway-alias 


Forward DRTR through an upstream proxy host or 
group or SOCKS gateway aliases. 
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Configuring i-FILTER 

Use the ProxySG Management Console or the CLI to configure Digital Arts i-FILTER content filtering. 

To Configure i-FILTER Content Filtering through the Management Console 

1. Select Configuration>Content Filtering>i-FILTER. 



Digital Aits i-FILTER | Automatic Download 




Figure 18-9: i-Filter Configuration Tab 

2. Enter the username and password assigned to you for downloading the i-FILTER database: enter 
your username into the Username field and click Change Password to enter or change your 
password. 

3. The default database download location is displayed in the URL field. If you have been instructed 
to use a different URL, enter it here. You can restore the default at any time by clicking Set to 
default. 

4. (Optional) To download the i-FILTER database immediately, complete the following steps. 



Note: You can return here at any time to download a database on demand (remember that the 

automatic download feature, if configured, keeps you up-to-date — see "Scheduling 
Automatic Downloads for Third-Party Vendors" on page 832). 

Ordinarily, the ProxySG checks to see if the database has changed before initiating a 
download. If the database is up to date, then no download is necessary and none is 
performed. If an incremental update is available on the server, then it is downloaded (an 
incremental update contains only the changes between the current installed version and 
the latest published version of the database, and is much smaller than a full copy of the 
database). 



a. Click Download Now. 

The i-FILTER Installation status dialog displays with the message: i-FILTER download in 
progress. 

When the operation completes, the dialog changes to indicate installation status. 
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b. Click Results to see the i-FILTER download log: 

Download log: 

i-FILTER download at: Tue , 28 June 2005 20:16:16 UTC 

Downloading from https://list.bluecoat.com/. . . /download/digitalarts . db 
Warning: Unable to determine current database version; requesting full update 



Download size: 


30274340 


Database date : 
Database expires: 
Database version: 


Tue, 7 June 2005 07:02:08 UTC 
Tue, 7 June 2005 07:02:08 UTC 
2 
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To Configure i-FILTER Content Filtering through the CLI 

The following commands allow you to enter the InterSafe username and password and define the 
default URL and the default URL location. 

1. At the (config) command prompt, enter the following commands: 

SGOS# (config) content- filter 

SGOS# (config content-filter) i-filter 

SGOS# (config i-filter) download username username 
SGOS# (config i-filter) download password password 
-or- 

SGOS# (config i-filter) download encrypted-password encrypted-password 
SGOS# (config i-filter) download url {default | url} 



where: 



download username 


username 


Specifies the username assigned to you for 
database download. 


download 

encrypted- 

password 


encrypted password 


Allows you to take a password previously 
encrypted by the ProxySG and cut and paste the 
encrypted password on the same appliance (or 
another appliance if it shares the same 
password-display keyring). 

The primary use of the encrypted-password 
command is to allow the ProxySG to reload a 
password that it encrypted. 


download password 


password 


Specifies the password assigned to you for 
database download. 


download url 


default 


Specifies the use of the default download URL. 


url 


The URL is the i-FILTER URL. You can change 
it if directed to do so. 



2. (Optional) To download the database now, enter one of the following commands: 

SGOS# (config i-filter) download get-now 

where download get-now initiates an immediate database download. An incremental update is 
requested. 



Note: For information about scheduling automatic downloads of the i-FILTER database, see 

"Scheduling Automatic Downloads for Third-Party Vendors" on page 832. 



3. (Optional) View the configuration. 



806 



Chapter 18: Content Filtering 



SGOS# (config intersafe) view 

Status : Ready 

https : / /list . bluecoat . com/ . . . / download/ digitalarts . db 

Download Username: admin 

Automatic download: Enabled 

Download time of day (UTC) : 0 

Download on: sun, mon, tue, wed, thu, fri, sat 

Download log: 



i-FILTER download at: Tue, 28 June 2005 20:16:16 UTC 

Downloading from https://list.bluecoat.com/. . . /download/ digitalarts . db 
Warning: Unable to determine current database version; requesting full update 
Download size: 30274340 

Database date: Tue, 7 June 2005 07:02:08 UTC 
Database expires: Tue, 7 June 2005 07:02:08 UTC 
Database version: 2 



Configuring InterSafe 

Use the ProxySG Management Console or the CLI to configure InterSafe content filtering. 

To Configure InterSafe Content Filtering through the Management Console 

1. Select Configuration>Content Filtering>lnterSafe. 

InterSafe Automatic Download 




Figure 18-10: InterSafe Configuration Tab 

2. Enter the username and password assigned to you for downloading the InterSafe database: enter 
your username into the Username field and click the Change Password button to enter or change 
your password. 

3. The default database download location is displayed in the URL field. If you have been instructed 
to use a different URL, enter it here. You can restore the default at any time by clicking Set to 
default. 

4. (Optional) To download the InterSafe database immediately, complete the following steps. 
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Note: You can return here at any time to download a database on demand (remember that the 

automatic download feature, if configured, keeps you up-to-date — see "Scheduling 
Automatic Downloads for Third-Party Vendors" on page 832). 

Ordinarily, the ProxySG checks to see if the database has changed before initiating a 
download. If the database is up to date, then no download is necessary and none is 
performed. If an incremental update is available on the server, then it is downloaded (an 
incremental update contains only the changes between the currently installed version and 
the latest published version of the database, and is much smaller than a full copy of the 
database). 



a. Click Download Now. 



The InterSafe Installation status dialog displays with the message InterSafe download in 
progress. 

When the operation is complete, the dialog changes to indicate installation status, 
b. Click Results to see the InterSafe download log: 

Download log: 

InterSafe download at: 10 Sep 2006 20:16:16 UTC 

Downloading from https://list.bluecoat.com/. . . /download/ intersafe . db 
Warning: Unable to determine current database version; requesting full update 



Download size: 
Database date : 



8106572 

10 Sep 2006 07:02:08 UTC 



Database expires: 10 Oct 2006 07:02:08 UTC 
Database version: 3 



808 



Chapter 18: Content Filtering 



To Configure InterSafe Content Filtering through the CLI 

The following commands allow you to enter the InterSafe username and password and define the 
default URL and the default URL location. 



1 . 



At the (config) command prompt, enter the following commands: 

SGOS# (config) content-filter 

SGOS# (config content-filter) intersafe 

SGOS# (config intersafe) download username username 
SGOS# (config intersafe) download password password 



-or- 

SGOS# (config intersafe) 
SGOS# (config intersafe) 



download encrypted-password encrypted-password 
download url {default | url} 



where: 



download username 


username 


Specifies the username assigned to you for 
database download. 


download 

encrypted- 

password 


encrypted password 


Allows you to take a password previously 
encrypted by the ProxySG and cut and paste the 
encrypted password on the same appliance (or 
another appliance if it shares the same 
password-display keyring). 

The primary use of the encrypted-password 
command is to allow the ProxySG to reload a 
password that it encrypted. 


download password 


password 


Specifies the password assigned to you for 
database download. 


download url 


default 


Specifies the use of the default download URL. 


url 


The URL is the InterSafe URL. You can change it 
if directed to do so. 



2. (Optional) To download the database now, enter one of the following commands: 

SGOS# (config intersafe) download get-now 

where download get -now initiates an immediate database download. An incremental update is 
requested. 

For information about scheduling automatic downloads of the InterSafe database, see "Scheduling 
Automatic Downloads for Third-Party Vendors" on page 832. 

3. (Optional) View the configuration. 

SGOS# (config intersafe) view 

Status : Ready 

Download URL: 

https : / /list . bluecoat . com/ . . . / download/ intersafe . db 
Download Username: admin 

Automatic download: Enabled 

Download time of day (UTC) : 0 

Download on: sun, mon, tue, wed, thu, fri, sat 

Download log: 
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InterSafe download at: 28 Sep 2006 20:23:16 UTC 

Downloading from https://list.bluecoat.com/. . . /download/ intersafe . db 
Requesting differential update 

Warning: Unable to determine current database version; requesting full update 

Download size: 8106572 

Database date: 10 Sep 2006 07:02:08 UTC 

Database expires: 10 Oct 2006 07:02:08 UTC 

Database version: 3 



Configuring IWF 

Use the ProxySG Management Console or the CLI to configure Internet Watch Foundation content 
filtering. 



Note: IWF can be configured in addition to another content filter service. See "About the 

Internet Watch Foundation" on page 786. 



To Configure IWF Content Filtering through the Management Console 

1. Select Configuration>Content Filtering>IWF. 

IWF | Automatic Download | 




Figure 18-11: IWF Configuration Tab 

2. Enter the username and password assigned to you for downloading the IWF database: enter your 
username into the Username field and click the Change Password button to enter or change your 
password. 

3. The default database download location is displayed in the URL field. If you have been instructed 
to use a different URL, enter it here. You can restore the default at any time by clicking Set to 
default. 

4. (Optional) To download the IWF database immediately, complete the following steps. 
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Note: You can return here at any time to download a database on demand (remember that the 

automatic download feature, if configured, keeps you up-to-date — see "Scheduling 
Automatic Downloads for Third-Party Vendors" on page 832). 

Ordinarily, the ProxySG checks to see if the database has changed before initiating a 
download. If the database is up to date, then no download is necessary and none is 
performed. If an incremental update is available on the server, then it is downloaded (an 
incremental update contains only the changes between the current installed version and 
the latest published version of the database, and is much smaller than a full copy of the 
database). 



a. Click Download Now. 

The IWF Installation status dialog displays with the message IWF download in progress. 

When the operation is complete, the dialog changes to indicate installation status. 

b. Click Results to see the IWF download log: 

Download log: 

IWF download at: 10 Sep 2006 20:16:16 UTC 

Downloading from https://list.bluecoat.eom/.-./download/iwf.db 

Warning: Unable to determine current database version; requesting full update 

Download size: 8106572 

Database date: 10 Sep 2006 07:02:08 UTC 

Database expires: 10 Oct 2006 07:02:08 UTC 

Database version: 3 

To Configure IWF Content Filtering through the CLI 

The following commands allow you to enter the IWF username and password and define the default 
URL and the default URL location. 

1. At the (config) command prompt, enter the following commands: 

SGOS# (config) content- filter 

SGOS# (config content-filter) iwf 
SGOS# (config iwf) download username username 
SGOS# (config iwf) download password password 
-or- 

SGOS# (config iwf) download encrypted-password encrypted-password 
SGOS# (config iwf) download url {default | url} 



where: 



download username 


username 


Specifies the username assigned to you for 






database download. 
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download 

encrypted- 

password 


en cryp t e d_pa s sword 


Allows you to take a password previously 
encrypted by the ProxySG and cut and paste the 
encrypted password on the same appliance (or 
another appliance if it shares the same 
password-display keyring). 

The primary use of the encrypted-password 
command is to allow the ProxySG to reload a 
password that it encrypted. 


download password 


password 


Specifies the password assigned to you for 
database download. 


download url 


default 


Specifies the use of the default download URL. 


url 


The URL is the IWF URL. You can change it if 
directed to do so. 



2. (Optional) To download the database now, enter one of the following commands: 

SGOS# (config iwf ) download get -now 

where download get -now initiates an immediate database download. An incremental update is 
requested. 



Note: For information about scheduling automatic downloads of the IWF database, see 

"Scheduling Automatic Downloads for Third-Party Vendors" on page 832. 



Ready 

https : / /list . bluecoat . com/ . . . / download/ iwf . db 
admin 
Enabled 
0 

sun, mon, tue, wed, thu, fri, sat 



3. (Optional) View the configuration. 

SGOS# (config iwf) view 
Status : 

Download URL: 

Download Username: 

Automatic download: 

Download time of day (UTC) : 

Download on: 

Download log: 

IWF download at: 28 Sep 2006 20:23:16 UTC 

Downloading from https://list.bluecoat.eom/.-./download/iwf.db 
Requesting differential update 

Warning: Unable to determine current database version; requesting full update 

Download size: 8106572 

Database date: 10 Sep 2006 07:02:08 UTC 

Database expires: 10 Oct 2006 07:02:08 UTC 

Database version: 3 



Configuring Optenet 

Use the ProxySG Management Console or the CLI to configure Optenet content filtering. 

To Configure Optenet Content Filtering through the Management Console 
1. Select Configuration>Content Filtering>Optenet. 
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Optenet | Automatic Download 




Figure 18-12: Optenet Configuration Tab 

2. Enter the Optenet username and password: enter your username into the Username field and click 
Change Password to enter or change your password. 

3. The default database download location is displayed in the URL field. If you have been instructed 
to use a different URL, enter it here. You can restore the default at any time by clicking Set to 
default. 

4. (Optional) To download the Optenet database immediately, complete the following steps. 



Note: You can return here at any time to download a database on demand (remember that 

the automatic download feature, if configured, keeps you up-to-date — see 
"Scheduling Automatic Downloads for Third-Party Vendors" on page 832). 

Ordinarily, the ProxySG checks if the database has changed before initiating a 
download. If the database is up to date, then no download is necessary and none is 
performed. If an incremental update is available on the server, then it is downloaded 
(an incremental update contains only the changes between the current installed 
version and the latest published version of the database, and is much smaller than a 
full copy of the database). 



5. Click Download Now. 



The Optenet Installation status dialog box displays with the message Optenet download in 
progress. 

When the operation is complete, the dialog changes to indicate installation status. 

6. Click Results to see the Optenet download log: 

Download log: 

Optenet download at: Fri, 04 Mar 2005 21:21:06 UTC 
Downloading from 

https: //list . blue coat . com/ optenet /activity/ download/ optenet . db 
Warning: Unable to determine current database version; requesting full update 



Download size: 
Database date : 
Database expires: 
Database version: 



8681732 

Tue, 01 Mar 2005 17:27:03 UTC 
Thu, 31 Mar 2005 17:27:03 UTC 
2 
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To Configure Optenet Content Filtering through the CLI 

The following commands allow you to enter the Optenet username and password and define the 
default URL and the default URL location. 

1. At the (config) command prompt, enter the following commands: 

SGOS# (config) content- filter 

SGOS# (config content-filter) optenet 

SGOS# (config optenet) download username username 
SGOS# (config optenet) download password password 
-or- 

SGOS# (config optenet) download encrypted-password encrypted-password 
SGOS# (config optenet) download url {default | url} 



where: 



download username 


username 


Specifies the username assigned to you for 
database download. 


download 

encrypted-password 


encrypted_password 


Allows you to take a password previously 
encrypted by the ProxySG and cut and paste 
the encrypted password on the same appliance 
(or another appliance if it shares the same 
password-display keyring). 

The primary use of the encrypted-password 
command is to allow the ProxySG to reload a 
password that it encrypted. 


download password 


password 


Specifies the password assigned to you for 
database download. 


download url 


default 


Specifies the use of the default download URL. 


url 


The URL is the Optenet URL. You can change it 
if directed to do so. 



2. (Optional) To download the database now, enter one of the following commands: 

SGOS# (config optenet) download get-now 

where download get-now initiates an immediate database download. An incremental update is 
requested. 



Note: For information about scheduling automatic downloads of the Optenet database, see 

"Scheduling Automatic Downloads for Third-Party Vendors" on page 832. 



3. (Optional) View the configuration. 

SGOS# (config optenet) view 

Status : Ready 

Download URL: 

https: //list . blue coat . com/ optenet /activity/ download/ optenet . db 
Download Username: OPTENET-USER 

Automatic download: Enabled 

Download time of day (UTC) : 0 
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Download on: sun, raon, tue, wed, thu, fri, sat 

Download log: 

Optenet download at: Fri, 04 Mar 2005 21:29:41 UTC 
Downloading from 

https : //list .bluecoat . com/optenet/activity/download/ optenet . db 
Requesting differential update 

File has not changed since last download attempt; no download required 
Previous download: 

Optenet download at: Fri, 04 Mar 2005 21:21:06 UTC 
Downloading from 

https: //list .bluecoat . com/ optenet /activity/ download/ optenet . db 

Warning: Unable to determine current database version; requesting full update 

Download size: 8681732 

Database date: Tue, 01 Mar 2005 17:27:03 UTC 

Database expires: Thu, 31 Mar 2005 17:27:03 UTC 

Database version: 2 



Configuring Proventia Web Filter 

Use the ProxySG Management Console or the CLI to configure Proventia Web Filter content filtering. 

To Configure Proventia Web Filter Content Filtering through the Management Console 

1. Select Configuration>Content Filtering>Proventia. 

Proventia Web Filter | Automatic Download 




Figure 18-13: Proventia Web Filter Configuration Tab 

2. Enter the Proventia Web Filter username and password: enter your username into the Username 
field and click the Change Password button to enter or change your password. 

3. The default database download location is displayed in the URL field. If you have been instructed 
to use a different URL, enter it here. You can restore the default at any time by clicking Set to 
default. 

4. (Optional) To download the Proventia Web Filter database immediately, complete the following 
steps. 
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Note: You can return here at any time to download a database on demand (remember that 

the automatic download feature, if configured, keeps you up-to-date — see 
"Scheduling Automatic Downloads for Third-Party Vendors" on page 832). 

Ordinarily, the ProxySG will check to see if the database has changed before initiating 
a download. If the database is up to date, then no download is necessary and none is 
performed. If an incremental update is available on the server, then it is downloaded 
(an incremental update contains only the changes between the current installed 
version and the latest published version of the database, and is much smaller than a 
full copy of the database). 



a. Click Download Now. 

The Proventia Installation status dialog box displays with the message Proventia download in 
progress. 

When the operation is complete, the dialog changes to indicate installation status. 

b. Click Results to see the Proventia Web Filter download log: 

Download log: 

Proventia download at: 10 Jul 2006 18:54:43 UTC 
Downloading from 

http : / /list . bluecoat . com/proventia/ activity/download/proventia . db 
Requesting differential update 
Download size: 144913364 

Database date: 16 Jun 2006 09:40:34 UTC 
Database expires: 06 Feb 2106 06:28:16 UTC 
Database version: 16777216 

To Configure Proventia Web Filter Content Filtering through the CLI 

The following commands allow you to enter the Proventia Web Filter username and password and 
define the default URL and the default URL location. 

1. At the (config) command prompt, enter the following commands: 

SGOS# (config) content- filter 

SGOS# (config content-filter) proventia 
SGOS# (config proventia) download username username 
SGOS# (config proventia) download password password 
-or- 

SGOS# (config proventia) download encrypted-password encrypted-password 
SGOS# (config proventia) download url {default | url} 



where: 



download username 


username 


Specifies the username assigned to you for 






database download. 
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download 
encrypted- 
pas sword 


en cryp t e d_pa s sword 


Allows you to take a password previously 
encrypted by the ProxySG and cut and paste the 
encrypted password on the same appliance (or 
another appliance if it shares the same 
password-display keyring). 

The primary use of the encrypted-password 
command is to allow the ProxySG to reload a 
password that it encrypted. 


download password 


password 


Specifies the password assigned to you for 
database download. 


download url 


default 


Specifies the use of the default download URL. 


url 


The URL is the Proventia Web Filter URL. You 
can change it if directed to do so. 



2. (Optional) To download the database now, enter one of the following commands: 

SGOS# (config proventia) download get-now 

where download get-now initiates an immediate database download. An incremental update is 
requested. 



Note: For information about scheduling automatic downloads of the Proventia database, see 

"Scheduling Automatic Downloads for Third-Party Vendors" on page 832. 



3. (Optional) View the configuration. 

SGOS# (config proventia) view 

Status : Ready 

Download URL: 

http : / /list . bluecoat . com/proventia/ activity/download/proventia . db 
Download Username: 

Automatic download: Enabled 

Download time of day (UTC) : 0 

Download on: sun, mon, tue, wed, thu, fri, sat 

Download log: 

Proventia download at: 10 Jul 2006 19:21:51 UTC 
Downloading from 

http : //list . bluecoat . com/proventia/activity/download/proventia . db 
Requesting differential update 



Download size: 
Database date : 
Database expires: 
Database version: 



144913364 

Wed, 16 Jun 2004 09:40:34 UTC 
Sat, 06 Feb 2106 06:28:16 UTC 
16777216 
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Configuring SmartFilter 

Use the ProxySG Management Console or the CLI to configure SmartFilter content filtering. 

To Configure SmartFilter Content Filtering through the Management Console 

1. Select Configuration>Content Filtering>SmartFilter. 

SmartFilter Automatic Download 




0 Allow RDNS 0 Categorize search engine URLs by keyword 

Figure 18-14: SmartFilter Configuration Tab 

2. In the license key field, enter the customer serial number assigned you by SmartFilter. 

3. The default server is displayed. If you have been instructed to use a different server, enter the 
hostname or IP address here. 

4. (Optional) SmartFilter lookups can require use of reverse DNS to properly categorize a Web site. 
To disable the use of reverse DNS by SmartFilter, deselect Allow RDNS. 

Important: Disabling reverse DNS prevents SmartFilter from correctly classifying some sites 

and can increase the likelihood of the ProxySG serving inappropriate content. 

5. (Optional) By default, SmartFilter categorizes search engines based on keywords in the URL 
query. To disable this setting, deselect Categorize search engine URLs based on keywords. 

Note: Leaving keywords enabled can cause unexpected results. For example, the keyword 

electoral college falls into the educational category. 

6. Click Apply. 

7. (Optional) To download the SmartFilter database immediately, complete the following steps. 
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Note: You can return here at any time to download a database on demand (remember that 

the automatic download feature, if configured, keeps you up-to-date — see 
"Scheduling Automatic Downloads for Third-Party Vendors" on page 832). 

Ordinarily, the ProxySG checks if the database has changed before initiating a 
download. If the database is up to date, then no download is necessary and none is 
performed. If an incremental update is available on the server, then it is downloaded 
(an incremental update contains only the changes between the current installed 
version and the latest published version of the database, and is much smaller than a 
full copy of the database). 



a. Click Download Now. 



The SmartFilter Installation status dialog box displays with the message SmartFilter download in 
progress. 



a. 



When the operation is complete, the dialog changes to indicate installation status. 
Click Results to see the completion message: 



Download log: 

SmartFilter download at: 06 Apr 2006 20:27:14 UTC 
Checking incremental update 

Warning: Unable to open input control list 
Warning: Unable to open installed control list 
Downloading full control file 

SmartFilter download at: 06 Apr 2006 20:27:14 UTC 
Downloading from http : //example . com/ ... version=4 . 0 
Download size: 45854194 

Database version: 95 

Database date: 06 Apr 2006 07:05:01 UTC 
Database expires: 11 May 2006 07:05:01 UTC 



Note: The first time you download a SmartFilter database, warnings appear in the 

results message under Checking incremental update. These are expected, and 
represent the normal process of checking to see if an incremental update is 
possible. The next time you download a SmartFilter database, the ProxySG checks 
the previously downloaded database, and download only what is necessary to 
keep the database current. 



To Configure SmartFilter Content Filtering through the CLI 

The following commands allow you to select a SmartFilter version, enter a username, specify a URL 
from which the database is to be downloaded, and do an immediate download of the SmartFilter 
database. 
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1. At the (config) command prompt, enter the following commands: 

SGOS# (config) content- filter 

SGOS# (config content-filter) smartfilter 

SGOS# (config smartfilter) download license license_key 

SGOS# (config smartfilter) download server ip_address_or_hostname 

SGOS# (config smartfilter) allow-rdns | no allow-rdns 

SGOS# (config smartfilter) use -search- keywords 



where: 



download license 


license key 


The customer serial number assigned you by 
SmartFilter. 


download server 


ip address or 
hostname 


Enter the IP address or hostname of the 
server you should use for downloads. 


allow-rdns 


no 


A toggle that enables or disables reverse DNS 
lookup. 


use-search- 

keywords 


no 


Allows you to categorize search engines 
based on keywords in the URL query. 



2. (Optional) To download the database now, enter one of the following commands: 

SGOS# (config smartfilter) download get-now 

where download get -now initiates an immediate database download. An incremental update is 
requested. 



Note: For information about scheduling automatic downloads of the SmartFilter database, see 

"Scheduling Automatic Downloads for Third-Party Vendors" on page 832. 



3. 



(Optional) View the configuration. 



SGOS# (config smartfilter) view 
Status : 

Download URL: 

Download Username: 

Automatic download: 

Download time of day (UTC) : 
Download on: 

Category review message: 

Allow RDNS for lookups: 



Ready 

list . smartfilter . com 
cf 00100002 
Enabled 
0 

sun, mon, tue, wed, thu, 

Disabled 

No 



Download log: 

SmartFilter download at: 02 Jul 2006 00:13:08 UTC 
Checking incremental update 

Installed database version: 152 
Current published version: 153 

Incremental download complete 
Download size: 42821832 

Database version: 153 

Database date: 01 Jul 2006 07:05:00 UTC 
Database expires: 05 Aug 2006 07:05:00 UTC 



fri, sat 
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Configuring SurfControl 

Use the ProxySG Management Console or the CLI to configure SurfControl content filtering. 

To Configure SurfControl Content Filtering through the Management Console 

1. Select Configuration>Content Filtering>SurfControl. 



SurfControl Automatic Download 




Figure 18-15: SurfControl Configuration Tab 

2. Enter the SurfControl username and password: enter your username into the Username field and 
click the Change Password button to enter or change your password. 

3. The default database download location is displayed in the URL field. If you have been instructed 
to use a different URL, enter it here. You can restore the default at any time by clicking Set to 
default. 



Important: If you are an existing SurfControl user, you must do a full download of the new 

SurfControl database before any filtering can be done. Until such time, all URLs are 
categorized as unavailable. 



4. (Optional) To download the SurfControl database immediately, complete the following steps. 



Note: You can return here at any time to download a database on demand (remember that the 

automatic download feature, if configured, keeps you up-to-date — see "Scheduling 
Automatic Downloads for Third-Party Vendors" on page 832). 

Ordinarily, the ProxySG checks if the database has changed before initiating a download. 
If the database is up to date, then no download is necessary and none is performed. 



a. Click Download Now . 

The SurfControl Installation status dialog box displays with the message SurfControl download 
in progress. 

When the operation is complete, the dialog changes to indicate installation status. 
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b. Click Results to see the SurfControl download log: 

Download log: 

Download log: 

SurfControl download at: Mon, 13 Feb 2006 09:01:16 UTC 
Downloading from 

https: //list. blue coat . com/ surf control /activity/ download/ surf control . db 
Download size: 141561056 

Database date: Fri, 10 Feb 2006 15:44:06 UTC 

Database expires: Thu, 11 May 2006 15:44:06 UTC 

Database version: 1420 

Database format: 1.1 



5. Click Apply. 



To Configure SurfControl Content Filtering through the CLI 

The following commands allow you to enter the username and define the default URL and the default 
URL location. 



1 . 



At the 

SGOS# 

SGOS# 

SGOS# 

SGOS# 



(conf ig) command prompt, enter the following commands: 

(config) content-filter 

(config content-filter) surfcontrol 



(config surfcontrol) 
(config surfcontrol) 



download username username 
download password password 



-or- 

SGOS# (config surfcontrol) 
SGOS# (config surfcontrol) 



download encrypted-password encrypted_password 
download url {default | url } 



where: 



download 

encrypted-password 


encrypted_password 


The download password, in encrypted format, 
assigned by Blue Coat. 


download password 


password 


The download password assigned by Blue 
Coat. 


download url 


default 


Specifies the use of the default download URL. 


url 


The URL is the SurfControl URL. You can 
change it if directed to do so. 


download username 


username 


The download username assigned by Blue 
Coat. 



2. (Optional) To download the database now, enter one of the following commands: 

SGOS# (config surfcontrol) download get-now 

where download get-now initiates an immediate database download. An incremental update is 
requested. 
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Note: For information about scheduling automatic downloads of the SurfControl database, see 

"Scheduling Automatic Downloads for Third-Party Vendors" on page 832. 



3. (Optional) View the configuration. 

SGOS# (config surfcontrol) view 
Status: Ready 

Download License key: 

Download log: 

Download log: 

SurfControl download at: Mon, 13 Feb 2006 09:01:16 UTC 
Downloading from 

https://list. blue coat . com/ surf control /activity/ download/ surfcontrol . db 
Download size: 141561056 

Database date: Fri, 10 Feb 2006 15:44:06 UTC 

Database expires: Thu, 11 May 2006 15:44:06 UTC 

Database version: 1420 

Database format: 1.1 



Using SurfControl Reporter with SGOS 4.x 

You can use the SurfControl Reporter with SGOS 4.x access logging to periodically upload 

information to the SurfControl Reporter reports database. 

After you create a SurfControl access logging client. Reporter periodically uploads flat files from the 

ProxySG. The files are then edited and deleted before loaded into the reports database. 

Working with SurfControl Reporter and SGOS 4.x requires several configuration steps. You must: 

□ Create and configure an access log with SurfControl as the client. For information on configuring 
a SurfControl access logging client, see "Editing the Custom SurfControl Client" on page 927. 

□ Download a SurfControl database and configure SurfControl as the content-filtering vendor. For 
information on downloading a SurfControl database and configuring SurfControl, see 
"Configuring SurfControl" on page 821. 

□ Configure the SurfControl server by installing Reporter and configuring the SurfControl 
Schedule. (Note that the schedule should not be the same as the ProxySG appliance's upload 
time.) For information on configuring the SurfControl server, refer to the SurfControl server 
documentation. 
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Configuring Websense 

Use the ProxySG Management Console or the CLI to configure Websense content filtering. 



Note: Websense databases contain a category called User-Defined to support locally-specified 

categorizations on other platforms. Do not use this category on the ProxySG. Instead, you 
can define your own categories through the ProxySG and assign URLs to them using 
Policy (see page "Defining Custom Categories in Policy" on page 837), or using a local 
category database (see "Create and Edit Policy Files" on page 556). 



To Configure the Websense Database through the Management Console 

1. Select Configuration>Content Filtering>Websense. 



Websense Automatic Download 




| [ Always apply regular expressions to URLs 

- Websense Reporter 

Integration Service Host: 

P°rt ; 0 ~| @ enabled 

I | Log forwarded client address 

Figure 18-16: Websense Configuration Tab 

2. Fill in the fields as appropriate: 

• License Key — Enter the license key assigned to you for downloading the Websense database. 

• Server — Enter the Websense server from which you wish to download. Your licensing 
information might suggest an alternate value; otherwise, use the default 
(download . websense . com). 

• Contact e-mail — (Optional) Enter an e-mail address through which Websense can contact you. 

• Always apply regular expressions to urls — (Optional) 

Select this option to force an additional regular expression lookup for each URL to be 
categorized. Normally, regular expression lookups are done only when no category is found 
in the Websense database. If this option is selected, regular expression lookups always occur, 
even for categorized URLs. Selecting this option can cause a significant reduction in lookup 
performance, but allow certain sites (such as translation, search engine, and link-cache sites) 
to be categorized more accurately. 

3. To use the Websense Reporter, you must enable the Websense Integration Service. 
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a. In the Integration Service Host field, enter the Integrator Service Host IP (which has the 
same IP address as the Websense Log Server). 

b. In the Port field, specify the port of the Websense Integration Service. It must be between 0 
and 65535 and match the port selected on the Integration Service host. 

c. Select Enabled to enable the service. 

d. (Optional): The Websense Reporter log normally includes the client connection's IP 
address. To log the address (if any) passed in the X-Forwarded-For HTTP Request header 
instead, enable this checkbox. 



Note: The Policy Server, the Log Server, and Reporter must be installed and enabled on 

your PC before Reporter can be used. For information on Websense products, refer to: 
http:/ /www. websense. com/support/ documentation/integrationservice. 

You must also set up access logging on the ProxySG with Websense as the client. For 
more information on configuring a Websense access logging client, see "Editing the 
Websense Client” on page 928. 



4. (Optional) To download the Websense database immediately, complete the following steps. 
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Note: You can return here at any time to download a database on demand (remember that 

the automatic download feature, if configured, keeps you up-to-date — see 
"Scheduling Automatic Downloads for Third-Party Vendors" on page 832). 

Ordinarily, the ProxySG checks if the database has changed before initiating a 
download. If the database is up to date, then no download is necessary and none is 
performed. If an incremental update is available on the server, then it is downloaded 
(an incremental update contains only the changes between the current installed 
version and the latest published version of the database, and is much smaller than a 
full copy of the database). 



e. Click Download Now. 



The Websense Installation status dialog box displays with the message Websense download in 
progress. 



f. 



When the operation is complete, the dialog changes to indicate installation status. 
Click Results to view the Websense download log: 



Download log: 

Websense download at: Fri, 10 Jun 2005 20:32:35 UTC 
No database is currently installed 
Attempting full download 
Downloading from download.websense.com 
Processing download file 
Retrieved full update 



Download size: 
Database version: 
Database date: 
License expires : 
License max users: 
Licenses in use: 
Library version: 



147079939 

82300 

2005-06-10 

Sun, 06 Nov 2005 08:00:00 UTC 
25 
0 

3 .2 . 0 . 0 [BCSI rev A] 



5. Click Apply. 

To Configure Websense through the CLI 

1. At the (config) command prompt, enter the following commands to configure the Websense 
download: 

SGOS# (config) content- filter 

SGOS# (config content-filter) websense 

SGOS# (config websense) download email-contact e-mail_address 
SGOS# (config websense) download server ip_address_or_hostname 
SGOS# (config websense) download license license_key 

2. (Optional) Enter the following command to configure regular expression lookups for each URL to 
be categorized. 

SGOS# (config websense) always -apply- regexes 
-or- 

SGOS# (config websense) no always -apply- regexes 
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where: 



download 
email -contact 


e-mail address 


(Optional) Specifies an e-mail address through 
which Websense can contact you. 


download server 


ip address or 
hostname 


Specifies the Websense server from which you 
wish to download. Your licensing information 
might suggest an alternate value; otherwise, use 
the default (download . websense . com). 


download license 


license key 


Specifies the license key assigned to you for 
downloading the Websense database. 


always - apply- regexes 




Forces an additional regular expression lookup 
for each URL to be categorized. 

Normally, regular expression lookups are done 
only when no category is found in the Websense 
database. If this optional command is selected, 
regular expression lookups always occur, even 
for categorized URLs. Selecting this option can 
cause a significant reduction in lookup 
performance, but can allow certain sites (such as 
translation, search engine, and link-cache sites) 
to be categorized more accurately. 

The default setting is no 

always -apply-regexes; you should change 
the default only if you are certain that you need 
the advanced setting. 


no 

always -apply- regexes 




Causes regular expression lookups to be done 
only when no category is found in the Websense 
database. This is the default setting. 



3. (Optional) To download the database now, enter one of the following commands: 

SGOS# (config websense) download get-now 

where download get-now initiates an immediate database download. An incremental update is 
requested. 



Note: For information about scheduling automatic downloads of the Websense database, see 

"Scheduling Automatic Downloads for Third-Party Vendors" on page 832. 



4. (Optional) View the configuration. 
SGOS# (config websense) view 
Status : 

Download License key: 

Download Server: 

Email contact: 

Automatic download: 

Download time of day (UTC) : 
Download on: 

Use regular expression filters: 



Ready 

EBC123DEF456GHI789 
download . websense . com 

Enabled 

0 

sun, mon, tue, wed, thu, fri, sat 
No 
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Always apply regex filters: 
Integration Server: 
Integration Server host: 
Integration Server port: 



Yes 

Disabled 

0 



Download log: 

Websense download at: Fri, 10 Jun 2005 19:35:59 UTC 
Downloading from download.websense.com 
Processing download file 
Retrieved full update 



Download size: 
Database version: 
Database date : 
License expires: 
License max users : 
Licenses in use: 
Library version: 



147079939 

82300 

2005-06-10 

Sun, 06 Nov 2005 08:00:00 UTC 
25 
0 

3 .2 . 0 . 0 [BCSI rev A] 



To Configure the Websense Integration Service through the CLI 

Enter the following commands to enable (or disable) and configure the Websense Integration Service 
through the CLI 

SGOS# (config) content- filter 

SGOS# (config content-filter) websense 

SGOS# (config websense) integration- service {enable | disable} 

SGOS# (config websense) integration- service host ip_address_or_hostname 
SGOS# (config websense) integration- service port integer 

where: 

• hos t specifies the hostname or IP address of the Websense Integration Service, which is 
the name or IP address of the Websense Log Server. 

• port specifies the port of the Websense Integration Service, must be between 0 and 65535, 
and match the port selected on the Integration Service host. 



Note: The Policy Server, the Log Server, and Reporter must be installed and enabled on 

your PC before Reporter can be used. For information on Websense products, refer to: 
http : / / www.websense.com / support / documentation / integrationservice. 

You must set up access logging on the ProxySG with Websense as the client. For more 
information on configuring a Websense access logging client, see "Editing the 
Websense Client" on page 928. 



Configuring Webwasher URL Filter 

Use the ProxySG Management Console or the CLI to configure Webwasher URL Filter content 
filtering. 
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To Configure Webwasher URL Filter Content Filtering through the Management Console 

1. Select Configuration>Content Filtering>Webwasher. 

Webivashei URL Filter | Automatic Download 




Figure 18-17: Webwasher URL Filter Configuration Tab 

2. Enter the Webwasher URL Filter username and password: enter your username into the Username 
field and click Change Password to enter or change your password. 

3. The default database download location is displayed in the URL field. If you have been instructed 
to use a different URL, enter it here. You can restore the default at any time by clicking Set to 
default. 

4. (Optional) To download the Webwasher URL Filter database immediately, complete the 
following steps. 



Note: You can return here at any time to download a database on demand (remember that 

the automatic download feature, if configured, keeps you up-to-date — see 
"Scheduling Automatic Downloads for Third-Party Vendors" on page 832). 

Ordinarily, the ProxySG checks if the database has changed before initiating a 
download. If the database is up to date, then no download is necessary and none is 
performed. If an incremental update is available on the server, then it is downloaded 
(an incremental update contains only the changes between the current installed 
version and the latest published version of the database, and is much smaller than a 
full copy of the database). 



a. Click Download Now. 

The Webwasher Installation status dialog box displays with the message Webwasher download 
in progress. 

When the operation is complete, the dialog changes to indicate installation status. 
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b. Click Results to see the Webwasher URL Filter download log: 

Download log: 

Webwasherdownload at: 10 Jul 2006 18:54:43 UTC 
Downloading from 

http : //list . bluecoat . com/webwasher/activity/download/webwasher . db 
Requesting full update 

Download size: 93484280 

Database date: Tue, 14 Dec 2004 22:38:14 UTC 

Database expires: Mon, 11 Jan 2016 06:31:29 UTC 

Database version: 900 



To Configure Webwasher URL Filter Content Filtering through the CLI 

The following commands allow you to enter the Webwasher URL Filter username and password and 
define the default URL and the default URL location. 



1. At the (config) command prompt, enter the following commands: 

SGOS# (config) content- filter 

SGOS# (config content-filter) webwasher 

SGOS# (config webwasher) download username username 

SGOS# (config webwasher) download password password 



SGOS# (config webwasher) download encrypted-password encrypted-password 
SGOS# (config webwasher) download url {default | url} 



where: 



download username 


username 


Specifies the username assigned to you for 
database download. 


download 

encrypted- 

password 


encrypted_password 


Allows you to take a password previously 
encrypted by the ProxySG and cut and paste 
the encrypted password on the same appliance 
(or another appliance if it shares the same 
password-display keyring). 

The primary use of the encrypted-password 
command is to allow the ProxySG to reload a 
password that it encrypted. 


download password 


password 


Specifies the password assigned to you for 
database download. 


download url 


default 


Specifies the use of the default download URL. 


url 


The URL is the Webwasher URL Filter URL. 
You can change it if directed to do so. 



2. (Optional) To download the database now, enter one of the following commands: 

SGOS# (config webwasher) download get -now 

where download get -now initiates an immediate database download. An incremental update is 
requested. 
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Note: For information about scheduling automatic downloads of the Webwasher URL Filter 

database, see "Scheduling Automatic Downloads for Third-Party Vendors" on page 832. 



3. (Optional) View the configuration. 

SGOS# (config webwasher) view 

Status : Ready 

Download URL: 

https: //list . blue coat . com/ webwasher /activity/ download/ webwasher . db 
Download Username: 

Automatic download: Enabled 

Download time of day (UTC) : 0 

Download on: sun, mon, tue, wed, thu, fri, sat 

Download log: 

Webwasher download at: 14 Dec 2006 20:52:58 UTC 
Downloading from 

https : //list . bluecoat . com/webwasher/activity/ download/webwasher . db 
Requesting full update 



Download size: 
Database date: 
Database expires : 
Database version: 



93484280 

Tue, 14 Dec 2004 22:38:14 UTC 
Mon, 11 Jan 2016 06:31:29 UTC 
900 
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Scheduling Automatic Downloads for Third-Party Vendors 



Note: By default, the automatic download setting is enabled (for every day at midnight, UTC) 

and does not need to be configured unless you want to change the schedule or disable 
auto-download. 



The Automatic Download tab allows you to set the times at which the database is downloaded. You 
can specify an automatic download on the day and time you prefer. Because sites become stale 
quickly. Blue Coat recommends downloading on an automatic schedule frequently. 

When the database is downloaded, a log is available that includes the information about how the 
database was updated, but in a more detailed form. You can view the download log through the 
Management Console (Statistics>Advanced>Content Filter Service) or the CLI (SGOS# (conf ig) show 
content- filter status). 



To Set Third-Party Automatic Download Times through the Management Console 

1. Select Configuration>Content Filtering; select your third-party vendor and select the Automatic 
Download tab. (The SurfControl Automatic Download tab is shown in the example below.) 



Optenet Automatic Download 

Automatic download: 



0 Download new filter at 

0 Sunday 
0 Wednesday 



midnight 



0 Monday 
0 Thursday 



UTC on the following days: 



0 Tuesday 
0 Friday 



0 Saturday 

Figure 1 8-1 8: Third-Party Vendor Automatic Download Tab 



2. To set up a schedule for database downloads, select the Download new filter at checkbox and select 
the time of day from the drop-down list. The default is Midnight. 

3. All days are selected by default. Deselect days as desired. 

4. Click Apply when finished. 

5. (Optional) To download a database right away (without creating a schedule), select the main tab 
of your third-party vendor and click the Download Now button. 

Downloading the database now does not affect the automatic database download schedule. 



To Set Third-Party Automatic Download Times through the CLI 



1 . 



At the (conf ig) command prompt, enter the following commands to enable or disable automatic 
downloading of the third-party vendor database. 

SGOS# (config) content-filter 

SGOS# (conf ig content-filter) third-party_vendor 
SGOS# (config third-party_vendor ) download auto 
-or- 



SGOS# (config third-party_vendor) no download auto 



where third-party_vendor is the command for your third-party vendor. 
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2. At the (config third- par ty_vendor ) command prompt, enter the following commands to 
select or deselect the day(s) to automatically download the local database. 

SGOS# (config third- par ty_vendor) download day-of-week {all | none | sun | mon 
| tue | wed | thu | fri | sat} 

-or- 

SGOS# (config third-party_vendor ) no download day-of-week {sun | mon | tue | 

wed | thu | fri | sat} 

where all selects all days of the week, and none clears all days of the week from the schedule. 

All days are selected by default; to deselect days, enter none and enter specific days. You can 
only select one day each time, but it is appended to the list. You can also use the no download 
day-of-week command to clear specific days from the schedule. 

3. Enter the following command to specify the hour (UTC) of the selected days during which the 
download should be performed. 

SGOS# (config third-party_vendor) download time-of-day 0-23 

4. (Optional) To download the database now, enter the following command: 

SGOS# (config third-party_vendor) download get -now 

Downloading the database now does not affect the automatic database download schedule. 

How to Apply Policy to Categorized URLs 

You apply policy to categories in the same way you apply policy to individual URLs: using Content 
Policy Language (CPL). To define policies on the ProxySG, you can either use the Visual Policy 
Manager (VPM) or you can manually edit policy files. For information about the VPM, see Chapter 14: 
"The Visual Policy Manager" on page 567; for information about managing policy files, see Chapter 
13: "Managing Policy Files" on page 553. 



Note: If you have extensive category definitions. Blue Coat recommends that you put them into 

a local database rather than into a policy file. The local database stores custom categories 
in a more scalable and efficient manner, and separates the administration of categories 
from policy. A local database does, however, have some restrictions that policy does not: 
no more than 200 separate categories are allowed, category names must be 32 characters 
or less, and a given URL pattern can appear in no more than four category definitions .You 
can choose to use any combination of the local database, policy files, and VPM to manage 
your category definitions. See "Configuring a Local Database" on page 791 for more 
information. 



The CPL trigger category= is used to test the category or categories assigned to the request URL, and 
thus make a policy decision. For example, to block all requests for URLs that are categorized as Sports: 
DENY category=Sports 

The following example demonstrates a condition that is true when a request contains the Websense 
content categories Sexuality and Drugs: 

<proxy> 

category= (sexuality, drugs) 

You can block multiple categories with a single rule: 
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category= (Sports , Gambling, Shopping) exception ( content_fil ter_denied) 

In this example, three categories are blocked and instead the predefined exception page 
content_filter_denied is served; by default this indicates that the request was denied due to its 
content and specifies the categories found. 

The following example shows a condition that includes an extensive number of categories: 

category^ (Abortion, Activist, Adult, Gambling, Illegal, Hacking, Militancy, 
Racism, Shopping, Tasteless, Violence, Weapons) 

URLs that are not categorized are assigned the system category none. This is not an error condition; 
many sites (such as those inside a corporate intranet) are unlikely to be categorized by a commercial 
service. Use category=none to detect uncategorized sites and apply relevant policy. The following 
example disallows access to uncategorized sites outside of the corporate network: 

define subnet intranet 

10.0.0.0/8 ; internal network 
192.168.123.45; external gateway 
end 

<proxy> 

; allow unrestricted access to internal addresses 
ALLOW url . address=intranet 

; otherwise (internet), restrict Sports, Shopping and uncategorized sites 
DENY category= (Sports , Shopping, none) 

Such category tests can also be combined with other types of triggers to produce more complex 
policy, such as: 

□ Restrict access by category and time: block sports from 6 am to 6 pm: 
category=Sports time=0600 . . 1800 DENY 

□ Restrict by category and user identity: only members of the group Sales are permitted to visit 
Shopping sites: 

category=Shopping group=! Sales DENY 

□ Require special authentication for access to certain categories: 
category=Hacking authenticate ( restricted_realm ) 

where restricted_realm is an authentication realm you have configured. 

□ Log certain types of access: 

category=Adult action. Log_adult_site_access (yes) 

where Log_adult_site_access is a policy action defined elsewhere that records extra 
information about this request in the event log. 

In general, category= can be used in policy anywhere that a basic URL test can be used. Refer to the 
Blue Coat ProxySG Content Policy Language Guide for more details. 

Depending on which provider you have selected and whether you have defined any of your own 
categories in policy (see "Defining Custom Categories in Policy" on page 837), you have a number of 
possible category names that can be used with category=. To review the valid category names, use 
the categories CLI command or click View Categories in the Management Console (as described in 
"Selecting Category Providers" on page 787). 
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The category= expressions are normally put in <Proxy> Layers (Web Access Layers in the VPM), 
because the goal of content-filtering policy is usually to control requests from users. They can also be 
used in <Cache> (Web Content in the VPM) Layers. Either way, policy is enforced on all user requests. 

It is possible for an attempt to categorize a URL to fail — for example, if no database is loaded, your 
license is expired, or if a system error occurs. In such a case, the category is considered unavailable and 
triggers such as: 

category=Sports 

are false, even if the URL is actually a Sports site, because the ProxySG is unable to determine the 
category. When the policy depends on the category of a URL, you do not want such errors to 
inadvertently allow ordinarily restricted content to be served by the ProxySG. You can control how 
the ProxySG treats these situations with the condition: 
cat egory=unavai table 

which is true in these cases. In continuing with the example, to make sure that Sports is always 
blocked, even when errors occur (this is a mode of operation called fail-closed), use a rule such as: 
category= ( sports , unavailable) exception (name_of_exception page) 

This rule is true if the category is sports or if the category could not be determined, and in either case 
the proper exception page is served instead of the restricted content. 

The category unlicensed is assigned in addition to unavailable when the failure to categorize occurred 
because of license expiry. That can be caused by the expiration of your Blue Coat license to use content 
filtering, or because of expiration of your license from the provider. You can use 
category=unlicensed 

to detect this situation as a distinct case from other causes of unavailability. 

You can also use this feature with custom exception pages (see Chapter 15: "Advanced Policy" on 
page 705): 

<proxy> 

category=sports time=0800. .1800 exception ( sports_during_bus_hrs) 
category=unlicensed exception ( contact_admin_re_license ) 
category=unavailable exception ( content_filter_unavailable ) 

where sports_during_bus_hrs is a custom exception page you have created to respond to 
requests for Sports pages between 8 am and 6 pm local time. 

contact_admin_re_license is another page that instructs the user to inform the 
administrator about license expiry, and is served if a license check fails. When the 
category is unavailable for some other reason, the pre-defined exception 
( content_filter_unavailable ) is served. 

The most common reason (other than license expiry) why categories are unavailable is that a provider 
is selected but no database is installed. Barring hardware or network problems that might cause a 
downloaded database to become corrupted and unreadable, it is unlikely that the database will 
suddenly become unavailable. 

To define policies on the ProxySG, use either the Visual Policy Manager or manually edit Policy files. 

Content filtering policies are usually found in <Proxy> and <Cache> layers. 

If you are using content filtering to manage a type of content globally, create these rules in the 
<Cache> layer. 
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However, if your content filtering policy is dependent on user identity or request characteristics, 
create these rules in the < Proxy > layer. 

Using Content-Filtering Vendors with ProxySG Policies 

The ProxySG provides the ability to define flexible Web access and control policies. With content 
filtering, you can set up policies to provide a customized level of Web-site access control. With 
vendor-based content filtering, these policies use and can supplement vendor categories. By 
supplementing content- filtering vendor categories, you can further refine the type of content filtering 
the ProxySG performs. For example, if Travel is a vendor-defined content category, you can define a 
policy that allows only Human Resources staff to access travel sites. You can define policies that filter 
by a variety of conditions, including category, protocol (including MMS and RTSP streaming 
protocols), time of day, and user or user groups. 

Example 

Policy: Limit employee access to travel Web sites. 

The first step is to rephrase this policy as a set of rules. In this example, the model of a general rule and 
exceptions to that rule is used: 

□ Rule 1 : All users are denied access to travel sites 

□ Rule 2: As an exception to the above. Human Resources users are allowed to visit Travel sites 

Before you can write the policy, you must be able to identify users in the Human Resources group. 
You can do this with an external authentication server, or define the group locally on the ProxySG. 
For information on identifying and authenticating users, see Chapter 9: "Using Authentication 
Services" on page 339. 

In this example, a group called human_resources is identified and authenticated through an external 
server called my_auth_server. 

This then translates into a fairly straightforward policy written in the local policy file: 

<proxy> 

; Ensure all access is authenticated 
Authenticate (my_auth_server ) 

<proxy> 

; Rule 1 : All users denied access to travel 
DENY category=travel 

<proxy> 

; Rule 2 : Exception for HR 

ALLOW category=travel group=human_resources 
DENY category=sites 

Example 

Policy: Student access to Health sites is limited to a specified time of day, when the Health 100 class is 
held. 

This time the policy contains no exceptions: 

□ Rule 1: Health sites can be accessed Monday, Wednesday, and Friday from 10-llam. 

□ Rule 2: Health sites can not be accessed at other times. 
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define condition Health_class time 
weekday=(l, 3, 5) time=1000 . . 1100 

end 

<proxy> 

; 1) Allow access to health while class in session 
ALLOW category=health condition=health_class_time 
; 2) at all other times, deny access to health 
DENY category=health 

Defining Custom Categories in Policy 

You can use CPL to create your own categories and assign URLs to them. This is done with the 
define category construct (for more complete information on the define category construct, refer to 
Blue Coat ProxySG Content Policy Language Guide). To add URLs to a category, list them in the 
definition. You only need to specify a partial URL: 

□ hosts and subdomains within the domain you specify will automatically be included 

□ if you specify a path, all paths with that prefix are included (if you specify no path, the whole site 
is included) 

Example: 

define category Grand_Canyon 
kaibab . org 

www2 . nature . nps . gov/ air/webcams/parks/grcacam 
nps . gov/grca 
grandcanyon . org 
end 

Any URL at kaibab . org is now put into the Grand_Canyon category (in addition to any category it 
might be assigned by a provider). Only those pages in the /grca directory of nps . gov are put in this 
category. 

Nested Definitions and Subcategories 

You can define subcategories and nest category definitions by adding a category=<name> rule. To 
continue the example, you could add: 

define category Yellowstone 
yellowstone-natl -park . com 
nps . gov/yell/ 
end 

define category National_Parks 

category=Grand_Canyon; Grand_Canyon is a subcategory of National_Parks 
category=Yellowstone ; Yellowstone is a subcategory of National_Parks 
nps.gov/yose; Yosemite - doesn't have its own category (yet) 
end 

With these definitions, pages at kaibab . org are assigned TWO categories: Grand_Canyon and 
National_Parks. You can add URLs to the Grand_Canyon category and they are automatically added 
by implication to the National_Parks category as well. 

Multiple unrelated categories can also be assigned by CPL. For instance, by adding: 
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define category Webcams 

www2 . nature . nps . gov/ air/webcams/parks/grcacam 
end 

the URL, http : / /www2 . nature . nps . gov/ air/webcams/parks/grcacam/ grcacam . htm, will have 
three categories assigned to it: 

□ Grand_Canyon (because it appears in the definition directly) 

□ National_Parks (because Grand_Canyon is included as a subcategory) 

□ Webcams (because it also appears in this definition) 

However, the other sites in the Grand_Canyon category are not categorized as Webcams. This can be 
seen by testing the URL (or any other you want to try) using the Test button on the Management 
Console or the test-url command in the CLI, as described in "Selecting Category Providers" on 
page 787. 

You can test for any of these categories independently. For example, the following example is a policy 
that depends on the above definitions, and assumes that your provider has a category called Travel 
into which most national park sites probably fall. The policy is intended to prevent access to travel 
sites during the day, with the exception of those designated National_Parks sites. But the 
Grand_Canyon webcam is an exception to that exception. 

Example: 

<proxy> 

category=Webcams DENY 
category=National_Parks ALLOW 
category=Travel time =0800.. 1800 DENY 

Remember that you can use the Test button on the Management Console or the test -url command in 
CLI to validate the categories assigned to any URL. This can help you to ensure that your policy rules 
have the expected effect (refer to "Configuring Policy Tracing" in the Blue Coat ProxySG Content Policy 
Language Guide). 

If you are using policy-defined categories and a content-filter provider at the same time, be sure that 
your custom category names do not coincide with the ones supplied by your provider. You can also 
use the same names — this adds your URLs to the existing categories, and extends those categories 
with your own definitions. For example, if the webcam mentioned above was not actually categorized 
as Travel by your provider, you could do the following to add it to the Travel category (for the 
purpose of policy): 

define category Travel ; extending a vendor category 

www2.nature.nps.gov/air/webcams/parks/grcacam/ ; add the GC webcam 
end 



838 



Chapter 18: Content Filtering 



Note: The policy definitions described in this section can also be used as definitions in a local 

database. See "Configuring a Local Database" on page 791 for information about local 
databases. 



Tips 

□ When you use an expired database, the category unlicensed is assigned to all URLs and no lookups 
occur on the database. This can occur even if your download license with the database vendor is 
still valid, but you have not downloaded a database for a long time (databases expire after a 
certain number of days). You can view the date that your database expires (or expired) in the 
download log or by using the view command in the CLI. 

When you download a database through the CLI, you can see the download log as soon as the 
download is complete. To see the download log when you download a database through the 
Management Console, click Results in the Installation Status dialog when the download is 
complete. 

To see the last download log without doing another download, enter the following CLI (config) 
commands: 

SGOS# (config) content-filter 

SGOS# (config content-filter) view 

□ When your license with the database vendor expires, you can no longer download. This does not 
have an immediate effect — you can still use the database you have for a period of time. But 
eventually, the database expires and you receive the category unlicensed, as described above. 

□ If a requested HTTPS host is categorized in a content filtering database, then filtering applies. 
However, if the request contains a path and the categorization relies on the host/ relative path, 
content filtering only filters on the host name because the path is not accessible. This might result 
in a different categorization than if the host plus path were used. 

□ If you receive an error message when downloading a content-filtering database, check the error 
message (in the Management Console, click Results on the Installation status dialog; in the CLI, the 
results message appears in the event of an error). If you see an error message such as ERROR: 
HTTP 401 - Unauthorized, verify that you entered your username and password correctly. For 
example, the following error message was generated by entering an incorrect username and 
attempting to download a SmartFilter database: 

Download log: 

SmartFilter download at: Thu, 08 Apr 2006 18:03:08 UTC 
Checking incremental update 

Checking download parameters 
Fetching : http : / /example . com/ 

Warning: HTTP 401 - Unauthorized 
Downloading full control file 

SmartFilter download at: Thu, 08 Apr 2006 18:03:17 UTC 
Downloading from http://example.com/ 

Fetching : http : / /example . com/ 
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ERROR: HTTP 401 - Unauthorized 
Download failed 
Download failed 
Previous download: 
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To fill requests, the ProxySG must interact not only with the local network, but with the upstream 
network environment. To control upstream interaction, various options are supported, such as 
forwarding, SOCKS gateways, ICP (Internet Caching Protocol), and WCCP (Web Cache Control 
Protocol). 

□ The ProxySG forwarding system — Allows you to define the hosts and groups of hosts to which 
client requests can be redirected. Those hosts can be servers or proxies, including additional 
ProxySG Appliances. Rules to redirect requests are set up in policy. 

□ SOCKS gateways — SOCKS servers provide application level firewall protection for an enterprise. 
The SOCKS protocol provides a generic way to proxy HTTP and other protocols. For information 
on configuring SOCKS gateways, see "SOCKS Gateway Configuration" on page 867. 

□ ICP — Internet Caching Protocol (ICP) is a service to handle ICP queries from other caching devices 
looking for cached data. The devices that can access this service can be controlled. ICP can also be 
used by the ProxySG to locate cached data in other systems. For information on configuring ICP, 
see "Internet Caching Protocol (ICP) Configuration" on page 875. 

□ WCCP — WCCP is a Cisco® -developed protocol that allows you to establish redirection of the 
traffic that flows through routers. (For more information on WCCP, see Appendix C: "Using 
WCCP" on page 1087.) 

This chapter contains the following topics: 

n "Understanding Forwarding” on page 843 

□ "Understanding Forwarding Terminology" on page 845 

□ "Configuring Forwarding" on page 847 

□ "Using Forwarding Directives to Create an Installable List" on page 857 

□ "SOCKS Gateway Configuration" on page 867 

□ "Internet Caching Protocol (ICP) Configuration" on page 875 

□ "Using Policy to Manage Forwarding" on page 881 

Understanding Forwarding 

The ProxySG forwarding system lets you represent what the upstream network looks like to the 
ProxySG at the level of the Web addresses (URLs). Forwarding doesn't deal with the packet addressing 
associated with networking equipment such as switches, routers, and hubs. Forwarding allows you to 
send Web requests to something other than the IP address specified in the URL and organize how the 
Web traffic flows around the network. 
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The Proxy SG forwarding system encompasses the use of forwarding, upstream SOCKS gateways, 
load balancing, host affinity, health checks, and Internet Caching Protocol (ICP). The ProxySG 
forwarding system determines the upstream address a request is sent to and is fundamentally tied in 
with all of the protocol agents, including HTTP, HTTPS, streaming, and FTP, as well as the network 
configuration. The combination of forwarding with the ProxySG policy engine allows extremely 
flexible configuration and traffic management. 



Note: The ProxySG forwarding system is available for HTTP, HTTPS, FTP, Windows Media, 

RTSP, Telnet, and TCP tunnels. 



Understanding Load Balancing 

Load balancing is a way to share traffic requests among multiple upstream systems or multiple IP 
addresses on a single host. 

You can configure load balancing several ways: 

□ For individual hosts: If a host is DNS-resolved to multiple IP addresses, then that host's load 
balancing method (round-robin, least connections, or none) is applied to those IP addresses. The 
method is either explicitly set for that host or taken from the configurable global default settings. 

□ For groups, two load balancing choices are available: 

• Apply a load-balancing method to a group. The hashing option must be specifically disabled 
(it is enabled by default) before you can apply the load balancing method to a group. Without 
using a hash, all the IP addresses of all the members of the group are gathered together, and 
the group's method is applied across that entire set of IP addresses. 

• Use a hash. If you use a hash, load balancing is a two-step process: 

• Step one: Apply a hash, either to the domain name or the full URL. This hash value is 
used to select one member of the group. 

• Step two: The selected host is treated just as an individual host is treated; the only 
difference is that the load-balancing method configured for the group is used for the 
selected host. 

Understanding Host Affinity 

Host affinity is the attempt to direct multiple connections by a single user to the same group member. 
Take, for example, a Web site that uses shopping carts to allow customers to purchase items. The site 
might use load balancing with a group of Web servers working in parallel, but only one server in the 
group has state on a single user. If the user connections are sent to a different server, the server has no 
previous state on the user and might start over. 

Host affinity forces the user's connections to return to the same server until the user is idle for a 
configurable period of time. After a configurable period of inactivity, the host affinity times out and 
the fact that multiple connections belong to a single user is lost. 
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Host affinity allows you to use any of the following options: 

□ Use the client IP address to determine which group member was last used. When the same client 
IP sends another request, the connection is made to that recorded group member. 

□ Place a cookie in the response to the client. When further requests are sent from the client with the 
cookie, the data in the cookie is used to determine which group member the client last used. The 
connection is made to that recorded group member. 

□ For HTTPS, extract the SSL session ID name from the connection information. The session ID is 
used in place of a cookie to determine which group member was last used. The connection is 
made to that recorded group member. 

Using Load Balancing and Host Affinity Together 

By default, if you use load balancing, each connection is treated independently. That connection is 
made to whichever member of the load-balancing group that the load-balancing algorithm selects. The 
load balancing responsibility is to spread the connections around as much as possible so the load is 
shared among group members. 

If host affinity is configured, it is checked first to see if the request comes from a known client. If this is 
a first connection, the load-balancing algorithm selects the group member to target. The result of the 
load balancing is recorded by host affinity in its tables for use if that client connects again. 

Host affinity does not make a connection to a host that health checks report is down; instead, if host 
affinity breaks, the load-balancing algorithm selects a group member that is healthy, and affinity is 
re-established on that working group member. 

For information on configuring host affinity, see "Configuring Host Affinity" on page 854; for 
information on configuring load balancing, see "Configuring Load Balancing" on page 853. 

Understanding Forwarding Terminology 

Before you begin, you should be familiar with the following terms: 

Table 19.1: Forwarding Terminology 



Directives 


Directives are commands that can be used in installable lists to configure 
forwarding. For the list of available directives, see Table 19.2: "Forwarding 
Directives". For the list of ICP directives, see Table 19.4: "ICP Directives". 
See also forwarding Configuration. 


Forwarding Configuration 


Forwarding can be configured through the CLI or through adding directives 
to a text file and installing it as an installable list. Each of these methods (the 
CLI or using directives) is equal. You cannot use the Management Console to 
configure forwarding. 
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Table 19.1: Forwarding Terminology 



Fail Open/ Closed 


Failing open or dosed applies to forwarding hosts and groups and SOCKS 
gateways. Fail Open/ Closed applies when the health checks are showing 
sick for each forwarding or SOCKS gateway target in the applicable fail-over 
sequence. If no systems are healthy, the ProxySG fails open or closed, 
depending on the configuration. If closed, the connection attempt simply 
fails. 

If open, an attempt is made to connect without using any forwarding target 
(or SOCKS gateway). Fail open is usually a security risk; fail closed is the 
default if no setting is specified. 


Global Default Settings 


You can configure settings for all forwarding hosts and groups. These are 
called the global defaults. You can also configure private settings for each 
individual forwarding host or group. Individual settings override the global 
defaults. 


Host 


Upstream Web servers or proxies. 


Host Affinity 


Host affinity is the attempt to direct multiple connections by a single user to 
the same group member. Host affinity is closely tied to load balancing 
behavior; both should configured if load balancing is important. 


Host Affinity Timeout 


The host affinity timeout determines how long a user remains idle before the 
connection is closed. The timeout value checks the user's IP address, SSL ID, 
or cookie in the host affinity table. 


Installable Lists 


Installable lists, comprised of directives, can be placed onto the ProxySG in 
one of several methods: through creating the list through the ProxySG text 
editor, by placing the list at an accessible URL, or by downloading the 
directives file from the local system. 


Integrated Host Timeout 


An integrated host is an Origin Content Server (OCS) that has been added to 
the health check list. The host, added through the integrate new hosts 
property, ages out of the integrated host table after being idle for the 
specified time. The default is 60 minutes. 


Load Balancing 


The ability to share traffic requests among multiple upstream targets. Two 
methods can be used to balance the load among systems: 
least -connections or round- robin . 


SOCKS Proxies. 


SOCKS proxies are a generic way to proxy TCP and UDP protocols. The 
ProxySG supports both SOCKSv4/4a and SOCKSv5; however, because of 
increased username and password authentication capabilities and 
compression support. Blue Coat recommends that you use SOCKS v5. For 
information on using SOCKS proxies, see "Configuring a SOCKS Proxy" on 
page 223. 
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Configuring Forwarding 

Forwarding is configured through the CLI or through installable lists using directives. The CLI and 
the directives have been designed to be as similar as possible; the functionality is identical. 

High level steps to configure forwarding are: 

□ Create the forwarding hosts and groups, including parameters such as protocol agent and port 

□ Edit these hosts and groups; you can create settings that override the global defaults 

□ Create Load Balancing and Host Affinity values 

Creating Forwarding Hosts and Groups 

You can create a maximum of 32 groups, and each group can contain a maximum of 512 hosts. You can 
create 512 individual hosts that do not belong to any group. 

The only required entries under the create command (for a host) are the host_alias, hostname, a 
protocol, and a port number. The port number can be defined explicitly (such as http=8 0 8 0), or it can 
take on the default port value of the protocol, if one exists (such as http, and the default port value of 
8 0 is entered automatically). 



Note: The host/ group aliases cannot be CPL keywords, such as no, default, or forward. 



To create a host group, you must also include the group =group_name option. If this is the first mention 
of the group, group_name, then that group is automatically created with this host as its first member. 
Do not use this command when creating an independent host. 

Because the functionality of the CLI and the directives is so similar, detailed instructions are provided 
only for the CLI. Lor the list of available directives, see "Using Lorwarding Directives to Create an 
Installable List" on page 857. 



To Create the Host or Group 



1. At the (conf ig) command prompt, create a forwarding host: 
SGOS# (conf ig) forwarding 

SGOS# (config forwarding) create host_alias hostname 
[http[=port | =no] ] [https [=port | =no] ] [ftp [=port 
=no] ] [rtsp[=port | =no] ] [tcp=port] [telnet [=port 
[ssl-verify-server [=yes | =no] ] [group=group_name] 



[default -schemes] 

| =no] ] [mms [=port 
| =no] ] 

[server | proxy] 



[load-balance= {no | round-robin | least-connections}] [host-af f inity={no 
client-ip-address | accelerator-cookie}] [host-af finity-ssl= {no | 
client-ip-address | accelerator-cookie | ssl-session-id} ] 



where: 



host_alias 




This is the alias for use in policy. Define a 
meaningful name. 


host name 




The name of the host domain, such 
www . bluecoat . com, or its IP address. 
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default -schemes 




If you use default - schemes, all 
protocols, along with their default ports, are 
selected. This directive is only available for 
proxy hosts. 


http 

https 

ftp 

mras 

rtsp 

telnet 


=port | =no 


You must choose at least one protocol 
where port=l to 65535. If only one 
protocol is configured, the ProxySG 
configures the default port for that protocol. 
You can use default- scheme s and then 
eliminate protocols by selecting the protocol 
you do not want; for example, http=no. If 
you do not want to use the default ports for 
the protocols, you must also specify them 
here. 

HTTPS or Telnet protocols are not allowed if 
the host is a proxy. 


tcp 


=port 


If you choose to add a TCP protocol, a TCP 
port must be specified. 

TCP protocols are not allowed if the host is a 
proxy. 


ssl- verify- server 


=yes | =no 


You can set SSL to specify that the ProxySG 
checks the CA certificate of the upstream 
server. 

The default for ssl -verify- server is 
yes. To disable this feature, you must 
specify ssl-verify-server=no in the 
installable list or CLI. 

Note that the CPL property 

server . certificate .validate , if 

configured, overrides this setting. 


group 


=group name 


Group specifies the group to which this host 
belongs. If this is the first mention of the 
group group name then that group is 
automatically created with this host as its 
first member. 

The ProxySG uses load balancing to evenly 
distribute forwarding requests to the origin 
servers or group of proxies. Do not use the 
group = option when creating independent 
hosts. 


server | proxy 




Server specifies to use the relative path for 
URLs in the HTTP header because the next 
hop is a Web server, not a proxy server. The 
default is proxy. 


load-balance 


no | round- robin | 
least -connections 


Specifies the load-balance method, round 
robin or least connections. No disables load 
balancing. 
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host-affinity 


accelerator-cookie | 
client-ip-address | 
no 


Specifies which non-SSL host-affinity 
method to use (accelerator cookie or 
client-ip-address) or you can use no 
to disable non-SSL host affinity 


host-af f inity-ssl 


accelerator-cookie | 
client-ip-address | 
ssl-session-id | no 


Specifies which SSL host-affinity method to 
use (accelerator cookie, 
client-ip-address, or 
ssl-session-id) or you can use no to 
disable SSL host affinity. 



2. Repeat step 1 to create additional forwarding hosts or host groups. 

3. Complete the configuration by entering the following commands as necessary: 

SGOS# (config forwarding) download-via- forwarding disable | enable 

SGOS# (config forwarding) failure-mode closed | open 
SGOS# (config forwarding) integrated-host- timeout minutes 

SGOS# (config forwarding) delete {all | group group_name | host host_alias} 
SGOS# (config forwarding) path url 
SGOS# (config forwarding) no path 



where: 



download-via- forwarding 


enable | 
disable 


Specifies whether forwarding (and SOCKS 
gateways) are to be used or ignored when 
trying to download or upload documents, 
including installable lists and policy files. 


failure-mode 


closed | open 


Failing open or closed applies to forwarding 
hosts and groups. Fail Open/ Closed applies 
when the health checks are showing sick for 
each forwarding target in the applicable 
fail-over sequence. If no systems are healthy, 
the ProxySG fails open or closed, depending 
on the configuration. If closed, the connection 
attempt simply fails. 

If open, an attempt is made to connect without 
using any forwarding target. Fail open is 
usually a security risk; fail closed is the default 
if no setting is specified. 

This setting can be overridden by policy, (using 
the forward . fail open (yes [no) 
property). 


integrated-host- timeout 


minutes 


An integrated host is an Origin Content Server 
(OCS) that has been added to the health check 
list. The host, added through the 
integrate new hosts property, ages out 
after being idle for the specified time. The 
default is 60 minutes. 
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delete 


all | group 
group name | 
host 

host_alias 


Deletes all forwarding hosts and groups 
(delete all) or a specific forwarding group 
(delete group group name) or host 
(delete host host_alias). 


path 


url 


(Optional) Path specifies the download path 
to use if you download installable lists. 


no 


path 


No clears the network path URL to download 
forwarding settings. 



Editing a Forwarding Host 

Once you have created a forwarding host, you can edit its configuration. 



Note: If you edit a group, you can only modify its load balancing and host affinity settings. For 

information on editing a group, see "Editing a Forwarding Group" on page 852. 



To Edit the Settings of a Forwarding Host through the CLI 

1. At the (config) command prompt, enter the following commands to configure the settings of a 
forwarding host: 

SGOS# (config) forwarding 

SGOS# (config forwarding) edit host_alias 

SGOS# (config forwarding host_alias ) {ftp | http | https | nuns | rtsp | 
telnet} [port] 

SGOS# (config forwarding host_alias) group group_name 
SGOS# (config forwarding host_alias) host hostname 
SGOS# (config forwarding host_alias) host-affinity {method 
{accelerator-cookie | client-ip-address | default} | ssl-method 
{accelerator-cookie | client - ip-address | ssl-session-id | default} 

SGOS# (config forwarding host_alias) load-balance method {least-connections | 
default | round-robin} 

SGOS# (config forwarding host_alias ) proxy | server 
SGOS# (config forwarding host_alias) ssl -verify- server 
SGOS# (config forwarding host_alias ) tcp port 



where: 



ftp | 


http | 


[port] 


Adds the protocol and optional port for 


https 


| rams | 




this host if it was not set previously or 


rtsp 


telnet 




changes the port number for the 
specified protocol if it was. If you do 
not enter a port number, the default 
port number is used. 








HTTPS or Telnet protocols are not 
allowed if the host is a proxy. 
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tcp 


port 


Changes the port number for the TCP 
protocol for this host. You must enter a 
port number if you use the TCP 
protocol. 

TCP protocols are not allowed if the 
host is a proxy. 


group 


group name 


Changes the group membership for 
this host. 


host 


host_name 


Changes this host's name. 


host-affinity 


method 

(accelerator-cookie | 
client-ip-address | 
default) 


Sets which non-SSL host-affinity 
method to use (accelerator 
cookie or client-ip-address) or 
you can use default to specify the 
global method. 


ssl-method 

(accelerator-cookie | 
client-ip-address | 
ssl-session-id | default} 


Sets which SSL host-affinity method to 
use (accelerator cookie, 
client-ip-address, or 
ssl-session-id) or you can use 
default to specify the global 
method. 


load-balance 

method 


least-connections | 
round-robin | default 


Allows you to select the round-robin 
method or the least-connections 
method, or specify default to 
specify the global method. 


proxy 




Defines this host as a proxy instead of a 
server; any HTTPS, Telnet, or TCP port 
is deleted. 


server 




Defines this host as a server instead of a 
proxy. 


ssl-verify-server 




Sets SSL to specify that the ProxySG 
checks the CA certificate of the 
upstream server for this host. 



2 . 



(Optional) Enter the following commands to negate or disable settings for this host (only one 
setting can be negated at a time): 

SGOS# (config forwarding host_alias) no {ftp | http | https | mins | rtsp | tcp 
| telnet} 

-or- 

SGOS# (config forwarding host_alias) no group 
-or- 

SGOS# (config forwarding host_alias) no host-affinity (method | ssl-method} 
-or- 



SGOS# (config 



forwarding host_alias ) 



no load-balance method 



-or- 



SGOS# (config forwarding host_alias) 



no ssl-verify-server 



851 



Blue Coat Proxy SG Configuration and Management Guide 



where: 



no {ftp | http | 
https | rams | rtsp | 
tcp | telnet} 




Clears the specified protocol 
and port from this host. 


no group 




Removes this host from any 
and all groups. 


no host-affinity 


method | ssl-method 


Clears the specified method 
from this host. 


no load-balance 


method 


Clears the method from this 
host. 


no ssl -verify- server 




Disables SSL verification for 
this host. 



Example 

SGOS# (config) forwarding 
SGOS# (config forwarding) edit testhost 
SGOS# (config forwarding testhost) server 
ok 

SGOS# (config forwarding testhost) no ftp 
ok 

SGOS# (config forwarding testhost) exit 
SGOS# (config forwarding) exit 
SGOS# (config) 

Editing a Forwarding Group 

When you edit a group, you can only change the load-balance and host-affinity settings. 

To Edit a Group 

At the (config) command prompt, enter the following commands to configure the settings of a 
forwarding host: 

SGOS# (config) forwarding 

SGOS# (config forwarding) edit group_alias 

SGOS# (config forwarding group_alias) host-affinity {method 
{accelerator-cookie | client-ip-address | default} | ssl-method 
{accelerator-cookie | client-ip-address | ssl-session-id | default} 

SGOS# (config forwarding group_alias) load-balance hash {domain | no | url} 
SGOS# (config forwarding group_alias ) load-balance method {least-connections | 
default | round-robin} 
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where: 



host-affinity 


method 

(accelerator-cookie | 
client-ip-address | 
default) 


Sets which non-SSL host-affinity 
method to use (accelerator 
cookie or client-ip-address) or 
you can use default to specify the 
global method. 


ssl -method 

(accelerator-cookie | 
client-ip-address | 
ssl-session-id | default} 


Sets which SSL host-affinity method to 
use (accelerator cookie, 
client-ip-address, or 
ssl-session-id) or you can use 
default to specify the global 
method. 


load-balance 


hash {domain | default | 
url } 


If you use the hash for load balancing, 
you can choose to hash the domain or 
the full URL or you can use default 
to disable hashing, and the load 
balancing method applies across a 
group. 


method {least-connections 
| round-robin | default} 


If you use method for load balancing, 
you can select the round-robin method 
or the least-connections method, or 
specify default to specify the global 
method. 



Configuring Load Balancing 

Load balancing settings can be configured globally (for all forwarding hosts and groups), or load 
balancing can be configured to a host or group's private values. These private values override the 
global default settings. (For an overview of load balancing, see "Understanding Load Balancing” on 
page 844.) 

To Set Load Balancing Global Default Settings 

SGOS# (config) forwarding 

SGOS# (config forwarding) load-balance hash {domain | no | url) 

SGOS# (config forwarding) load-balance method {least-connections | no | 
round-robin} 



where: 



hash 


{domain | no | url} 


If you use the hash for load balancing, you can choose to 
hash the domain or the full URL or no to disable hashing, 
and the load balancing method applies across a group. 


method 


{least-connections | 
no | round-robin} 


If you use method for load balancing, you can select the 
round-robin method or the least-connections method, or 
specify no to disable load balancing. 
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Note: Remember that a group must have a hash setting of no in order for the method to apply 

across the entire group. 



To Set Load Balancing Private Values 

SGOS# (config) forwarding 

SGOS# (config forwarding) load-balance hash {default | domain | no | url} 

group_alias 

SGOS# (config forwarding) load-balance method {default | least-connections | 
no | round-robin} host_or_group_alias 

where: 



hash 


{default | domain | 
no | url} 
group_alias 


You can specify a group to apply the load-balancing hash 
setting to only that group. 


method 


{default | 
least-connections | 
no | round-robin} 
host_or_group_alias 


You can specify a host or group to apply the 
load-balancing method to only that host or group. 



Example 

SGOS# (config forwarding) load-balance method least-connections 

test -host -name 
ok 

Configuring Host Affinity 

Host affinity settings can be configured globally (for all forwarding hosts and groups), or it can be 
configured fort a host or group's private values. These private values override the global default 
settings. (For an overview of host affinity, see "Understanding Host Affinity" on page 844.). 

The non-SSL host affinity methods are implemented for HTTP only; SSL host affinity methods are 
implemented for HTTPS only. 

To Configure Global Default Host Affinity Settings 

SGOS# (config) forwarding 

SGOS# (config forwarding) host-affinity method {accelerator-cookie | 
client-ip-address | no} 

-or- 

SGOS# (config forwarding) host-affinity ssl-method {accelerator-cookie | 
client-ip-address | ssl-session-id | no} 

SGOS# (config forwarding) host-affinity timeout minutes 



where: 



method 


{accelerator-cookie | 


Sets which non-SSL host-affinity method to 




client-ip-address | no} 


use (accelerator cookie or 
client- ip -address) or you can use no to 
disable non-SSL host affinity. 
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ssl-method 


{accelerator-cookie | 
client-ip-address | 
ssl-session-id | no} 


Sets which SSL host-affinity method to use 
(accelerator cookie, 
client-ip-address, or 
ssl-session-id) or you can use no to 
disable SSL host affinity. 


timeout 


minutes 


Determines how long a user's IP address, 
SSL ID, or cookie remains valid. 



To Configure Host- or Group-Specific Host Affinity Settings 

SGOS# (config) forwarding 

SGOS# (config forwarding) host-affinity method {accelerator-cookie | 

client-ip-address | default | no} host_or_group_alias 

-or- 

SGOS# (config forwarding) host-affinity ssl-method {accelerator-cookie | 
client-ip-address | default | no} host_or_group_alias 



where: 



method 


{accelerator-cookie | 
client-ip-address | 
default | no} 
host_or_group_alias 


You can choose which non-SSL host-affinity 
method to use (accelerator cookie or 
client-ip-address) for a specific host or 
group, or you can use no to disable non-SSL 
host affinity for a specific host or group. You 
can also apply the global non-SSL host-affinity 
method to a specific host or group. 


ssl_method 


{accelerator-cookie | 
client-ip-address | 
default | no | 
ssl-session-id} 
host_or_group_alias 


You can choose which SSL host-affinity 
method to use (accelerator cookie, 
client-ip-address, or ssl-session-id) 
for a specific host or group, or you can use no 
to disable SSL host affinity for a specific host or 
group. You can also apply the global SSL 
host-affinity method to a specific host or group 
(use the default command). 



Example 

SGOS# (config forwarding) host-affinity method client-ip-address 

ok 

SGOS# (config forwarding) host-affinity ssl-method no test-group-name 
ok 

SGOS# (config forwarding) host-affinity timeout 45 
ok 

Creating a Default Sequence 

The default sequence defines the order in which forwarding hosts are used in case of failover and 
which host to use first (only one default sequence is allowed). If you create a default sequence, 
forwarding is applied, by default, to all requests. All members must be pre-existing hosts and groups, 
and no member can be in the group more than once. 
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Note: Creating a default sequence through the CLI is a legacy feature. Creating a default 

sequence can be done much more efficiently through policy — VPM or CPL — than it can 
through the CLI. The default sequence (if present) is applied only if no applicable 
forwarding gesture is in policy. 

For information on using VPM, see Chapter 14: "The Visual Policy Manager" on page 567; 
for information on using CPL, refer to the Blue Coat ProxySG Content Policy Language 
Guide. 



A default failover sequence (and any sequence specified in policy) works by allowing healthy hosts to 
take over for an unhealthy host (one that is failing its DNS Resolution or its health check). The 
sequence specifies the order of failover, with the second host taking over for the first host, the third 
taking over for the second, and so on. 



Note: In normal circumstances, only the first member of the sequence is ever used. 



If all hosts are unhealthy, the operation fails either open or closed, depending upon your settings. 

This configuration is generally created and managed through policy. If no forwarding policy applies, 
you can create a default sequence through the CLI. This single default sequence consists of a single 
default host (or group) plus one or more hosts to use if the preceding ones are unhealthy. 



To Create a Default Sequence through the CLI 



From the (config) prompt, enter the following commands: 



SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 



forwarding) 

forwarding) 

forwarding) 

forwarding) 

forwarding) 



sequence add alias_name 
sequence clear 
sequence demote alias_name 
sequence promote alias_name 
sequence remove alias_name 



where: 



add 


alias_name 


Adds an alias to the end of the default failover sequence. 


clear 




Clears the default failover sequence. 


demote 


alias_name 


Moves an alias one place towards the end of the default failover 
sequence. 


promote 


alias_name 


Moves an alias one place towards the start of the default failover 
sequence. 


remove 


alias_name 


Removes an alias from the default failover sequence. 



Example 

SGOS# (config forwarding) sequence clear 
ok 
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Note: Any host or group in the default sequence is considered in use by policy. As a result, if 

you try to delete a host or group while it is in the default sequence, you receive an error 
message. You must remove the host /group from the sequence first, then delete. 



Using Forwarding Directives to Create an Installable List 

You can use either directives or the CLI to create and configure forwarding hosts. To use the CLI, see 
"To Create Forwarding Settings on the ProxySG through the CLI" on page 865. 

The forwarding configuration includes directives that: 

□ Create the forwarding hosts and groups 



□ Provide load balancing and host affinity 
Table 19.2: Forwarding Directives 



Directive 


Meaning 


See 


fwd fail 


Determines whether the forwarding 
host should fail open or fail closed if 
an operation does not succeed. Fail 
open is a security risk. 


"Setting Fail Open/ Closed and Host 
Timeout Values" on page 860. 


fwd_host 


Create a forwarding host and set 
configuration parameters for it, 
including protocols and ports. 


"Creating Forwarding Host and Group 
Directives" on page 857. 


host_af f inity 


The attempt to direct multiple 
connections by a single user to the 
same group member. 


"Configuring Host Affinity Directives" 
on page 861. 


integrated host 
timeout 


An origin content server that has been 
added to the health check list is called 
an integrated host. The host ages out 
after being idle for the specified time. 


"Setting Fail Open/ Closed and Host 
Timeout Values" on page 860. 


load balance 


The attempt to manage the load 
among forwarding hosts in a group, or 
among multiple IP addresses of a host. 


"Configuring Load Balancing 
Directives" on page 860. 


sequence alias list 


where alias list is a space 
separated list of one or more 
forwarding host and group aliases. 


"Creating a Default Sequence" on 
page 861. 



Creating Forwarding Host and Group Directives 

You can add directives into the forwarding installable list that allows you to create and delete the 
forwarding host and associate protocols and ports with the host. 

You can create a maximum of 32 groups, and each group can contain a maximum of 512 hosts. You can 
create 512 individual hosts that do not belong to any group. 
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To create a forwarding host, choose the protocols you want to use, or optionally add the forwarding 
host to a group, enter the following into your installable list. Create a fwd host directive for each 
forwarding host you want to create. 

fwd_host host_alias hostname [default-schemes] [http [=port | =no] ] 

[https [=port | =no] ] [ftp [=port | =no] ] [rams [=port | =no] ] [rtsp [=port | 

=no] ] [tcp=port] [telnet [=port | =no] ] [ssl-verify-server [=yes | =no] ] 

[group =group_name] [server | proxy] [load-balance= {no | round-robin | 
least-connections}] [host-af f inity={no | client-ip-address | 
accelerator-cookie } ] [host-aff inity-ssl={no | client-ip-address | 
accelerator-cookie | ssl-session-id}] 



where: 



host_alias 




This is the alias for use in policy. Define a name 
meaningful to you. 


host name 




The name of the host domain, such 
www . bluecoat . com, or its IP address. 


def ault- 
schemes 




If you use default-schemes in the directive, all 
protocols, along with their default ports are selected. 
This directive is only available for proxy hosts. 


http 

https 

ftp 

mms 

rtsp 

telnet 


=port | =no 


No protocol is selected by default if the forwarding 
host is a server. You must choose at least one 
protocol where port=0 to 6 553 5. If only one 
protocol is configured, the ProxySG configures the 
default port for that protocol. 

You can use default - scheme s and then eliminate 
protocols by selecting the protocol you do not want; 
for example, http=no. If you do not want to use the 
default ports for the protocols, you must also specify 
them here. 

HTTPS protocols are not allowed if the host is a 
proxy. 


tcp 


=port 


If you choose to add a TCP protocol, a TCP port 
must be specified. 

TCP protocols are not allowed if the host is a proxy. 


ssl-verify- 

server 


=yes | =no 


Sets SSL to specify that the ProxySG checks the CA 
certificate of the upstream server. 

The default for ssl-verify-server is yes. To 
disable this feature, you must specify 
ssl -verify- server=no in the installable list or 
CLI. In other words, you can configure 
ssl -verify- server=yes in three ways: do 
nothing (yes is the default), specify 
ssl -verify- server, or specify 
ssl-verify-server=yes . 



858 



Chapter 19: Configuring the Upstream Networking Environment 



group 


= group name 


Specifies the group (or server farm or group of 
proxies) to which this host belongs. If this is the first 
mention of the group group name then that group 
is automatically created with this host as its first 
member. 

The ProxySG uses load balancing to evenly 
distribute forwarding requests to the origin servers 
or group of proxies. Do not use the group= option 
when creating independent hosts. 


server | 
proxy 




server specifies to use the relative path for URLs in 
the HTTP header because the next hop is a Web 
server, not a proxy server. The default is proxy. 


load-balance 


=no | = round- robin | 
= least -connect ions 


Specifies either the least-connections or round-robin 
method of load balancing. Select no to disable load 
balancing for this forwarding host or host group. 

If these settings are not specified for a particular host 
or host group, then the global default settings are 
used. To configure the settings for a specific host or 
host group, use the edit host alias or edit 
group alias commands (see "Editing a 
Forwarding Host" on page 850 or "Editing a 
Forwarding Host" on page 850). 


host-affinity 


=no | 

=client- ip- address 
1 

=accel era tor -cookie 


Specifies non-SSL host affinity via either a client IP 
address or an accelerator cookie. Select no to disable 
non-SSL host affinity for this forwarding host or host 
group. 

If these settings are not specified for a particular host 
or host group, then the global default settings are 
used. To configure the settings for a specific host or 
host group, use the edit host alias or edit 
group alias commands (see "Editing a 
Forwarding Host" on page 850 or "Editing a 
Forwarding Group" on page 852). 


host-af f inity 
-ssl 


=no | 

=client- ip- address 
1 

=accel era tor -cookie 
| =ssl-session-id 


Specifies SSL host affinity via a client IP address, an 
accelerator cookie, or an SSL session ID. Select no to 
disable SSL host affinity for this forwarding host or 
host group. 

If these settings are not specified for a particular host 
or host group, then the global default settings are 
used. To configure the settings for a specific host or 
host group, use the edit host alias or edit 
group alias commands (see "Editing a 
Forwarding Host" on page 850 or "Editing a 
Forwarding Group" on page 852). 



Example 

fwd_host www.bluecoatl.com 10.25.36.48 default -schemes ssl-verify-server=no 
group=bluecoat 
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Setting Fail Open/Closed and Host Timeout Values 

Using directives, you can determine if the forwarding host fails open or closed, if an operation does 
not succeed, and the interval it takes for integrated hosts to be aged out. 

An integrated host is an Origin Content Server (OCS) that has been added to the health check list. If 
the policy property integrate_new_hosts applies to a forwarding request. Blue Coat makes a note of 
each OCS and starts health checking to help future accesses to those systems. If the host is idle for the 
interval you specify, it is aged out. Sixty minutes is the default. 

The syntax is: 

fwd_fail {open | closed} 
integrated_host_timeout minutes 



where: 



fwd fail 


{open | 
closed} 


Determines whether the forwarding host 
should fail open or fail closed if an operation 
does not succeed. Fail open is a security risk, 
and fail closed is the default if no setting is 
specified. 

This setting can be overridden by policy, 
(using the forward . fail open (yes | no) 
property). 


integrated_host_timeout 


minutes 


An OCS that has been added to the health 
check list is called an integrated host. The 
host ages out after being idle for the specified 
time. 



Examples 

fwd_fail open 
integrated_host_timeout 90 



Configuring Load Balancing Directives 



Load balancing shares the load among a set of IP addresses, whether a group or a host with multiple 
IPs. 



The syntax is: 

load_balance hash {domain | no | url} [ group_alias ] 
load_balance method {least-connections | round-robin | no} 
[ host_or_group_alias ] 



where: 



hash 



{domain | no | url} 
[ group_alias ] 



If you use the hash for load balancing, you can hash the 
domain or the full URL, or you can enter no to disable 
hashing and the load-balancing method applies across a 
group. If you do not specify a group, the settings apply 
as the default for all groups. 
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method 


{least-connections | 


If you use method for load balancing, you can select the 




no | round-robin} 


least-connections method or the round-robin 




[ host_or_group_alias ] 


method, or you can specify no to disable load balancing 
(hashing still occurs if it is set). If you do not specify a 
host or group, the settings apply as the default for all 
hosts or groups. 



Example 

load_balance method least_connections 

Configuring Host Affinity Directives 

Host affinity is the attempt to direct multiple connections by a single user to the same group member. 
The syntax is: 

host_af f inity method {accelerator-cookie | client-ip-address | no} 

[ host_or_group_alias ] 

host_aff inity ssl_method {accelerator-cookie | client-ip-address | no | 
ssl- session- id} [ host_or_group_alias ] 
host_aff inity timeout seconds 



where: 



method 


{accelerator-cookie | 
client-ip-address | 
no} 

[ hos t_ or_group_ alias ] 


Determines which non-SSL host-affinity method to 
use (accelerator cookie or 
client - ip -address), or you can use no to disable 
non-SSL host affinity. If you do not specify a host or 
group, the settings apply as the default for all hosts 
or groups. 


ssl_method 


{accelerator-cookie | 
client-ip-address | no 
| ssl-session-id} 
[host_or_group_alias] 


Determines which SSL host-affinity method to use 
(accelerator cookie, client-ip-address, or 
ssl-session-id), or you can use no to disable SSL 
host affinity. If you do not specify a host or group, 
the settings apply as the default for all hosts or 
groups. 


timeout 


minutes 


Determines how long a user's IP address, SSL ID, or 
cookie remains valid. 



Example 

host_aff inity ssl_method 10.25.36.48 
host_aff inity timeout 5 

Creating a Default Sequence 

A default sequence defines the order in which forwarding hosts are used. Only one default sequence is 
allowed. All members must be pre-existing hosts and groups, and no member can be in the group 
more than once. 
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Note: The default sequence, completely overridden by policy, replaces the deprecated default 

and backup settings. 



A default failover sequence works by allowing healthy hosts to take over for an unhealthy host (one 
that is failing its DNS Resolution or its health check). The sequence specifies the order of failover, with 
the second host taking over for the first host, the third taking over for the second, and so on). 

If all hosts are unhealthy, the operation fails either open or closed, depending upon your settings. 

This configuration is generally created and managed through policy. If no forwarding policy applies, 
you can create a default sequence through the CLI. This single default sequence consists of a single 
default host (or group) plus one or more hosts to use if the preceding ones are unhealthy. 

The syntax is 

sequence alias_list alias_list 

where alias_list is a space-separated list of one or more forwarding host and group aliases. 

Example 

sequence bluecoat 

Creating a Forwarding Installable List 

You can create and install the forwarding installable list with the following methods: 

□ Use the ProxySG Text Editor, which allows you to enter the installable list of directives (or copy 
and paste the contents of an already-created file) directly onto the ProxySG. 

□ Create a local file on your local system; the ProxySG can browse to the file and install it. 

□ Enter a remote URL, where you placed an already-created file on an FTP or HTTP server to be 
downloaded to the ProxySG. 

□ Use the CLI inline command. 

When the Forwarding Installable List is installed, it updates the forwarding directives on the 
ProxySG. The directives remain in effect until they are overwritten by another installable list; the list 
can be modified or overwritten using CLI commands. 



Note: During the time that a forwarding installable list is being compiled and installed, 

forwarding is not available. Any transactions that come into the ProxySG during this time 
are not forwarded properly and are denied. 



Installation of forwarding installable lists should be done outside peak traffic times. 

To Create a Forwarding Installable List through the Management Console 
1. Select Configuration>Forwarding>Forwarding Hosts. 
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Forwarding Hosts 



- Install Forwarding Settings 



Install Forwarding Settings from: 



Remote URL v 



Install 



- View Forwarding Settings 



Forwarding Settings View the current Forwarding Settings 



| Apply || Cancel || Help | 

Figure 19-1: Selecting the Forwarding Hosts Download Method 

2. From the drop-down list, select the method to use to install the forwarding installable list; click 
Install. 



Note: A message is written to the event log when you install a list through the ProxySG. 



• Remote URL: 

Enter the fully-qualified URL, including the filename, where the installable list is located. To 
view the file before installing it, click View. Click Install. Examine the installation status that 
displays; click OK. 



Install Forwarding Settings 



Install Forwarding Settings 

Installation URL: 




OK ] ( Cancel | 

Figure 19-2: Specifying the Remote Location of a Forwarding Configuration 
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• Local File: 

Click Browse to display the Local File Browse window. Browse for the installable list file on 
the local system. Open it and click Install. When the installation is complete, a results window 
opens. View the results, close the window, click Close. 




Figure 19-3: Specifying the Local Location of a Forwarding Configuration 
• Text Editor: 

The current configuration is displayed in installable list format. You can customize it or delete 
it and create your own. Click Install. When the installation is complete, a results window 
opens. View the results, close the window, click Close. 



Upload and Install File 



HOME SUPPORT DOCUMENTATION LOO OUT 



BlueOCoat 

Systems 



Note: The Management Console text editor is a way to enter an installable list for 

forwarding. It is not a way to enter CLI commands. The directives are understood 
only by the installable list parser for forwarding. 
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BlueOCoat 

Systems 



Upload and Install File 



Edit and Install the Forwarding Settings 



□ 



HOME SUPPORT DOCUMENTATION LOO OUT 



1 . Edit the contents of the currently installed file in the box below. 

2. Click Install to upload and install the new contents. It can take some time for the upload to complete. 
Your browser may be unresponsive during the upload. 

3. Once the installation is completed the results will be displayed in a new page. Close the results page 
once you have finished viewing the results. 



# Current Forwarding Configuration 

# No update 

# Connection attempts to forwarding hosts fail: closed 
fwd_fail closed 

# Integrated hosts are deleted after this timeout in minutes 
integrated_host_timeout 60 

# 0 forwarding hosts defined (not in groups) , 512 maximum 

# Forwarding host configuration (no group) : 

# fwd_host <alias> <host-name> [default-schemes] [http [=<port> | no] ] [https 
[=<port> | no] ] 

# [f tp [=<port> | no] ] [mms [=<port> | no] ] [rtsp [=<port> | no] ] [tcp=<port>] 

# [ssl-ver if y-server [=yes | no] ] [server | proxy] 

# 0 forwarding groups defined, 32 maximum 

# Group forwarding host configuration: 

# fwd_host <alias> <host-name> [default-schemes] [http [=<port> | no] ] [https 

[=<port> | no] ] ▼ | 



Install | Close | 

Figure 19-4: Using the Proxy SG Text Editor 
3. Click Apply. 

To Create a Remote Forwarding Installable List through the CLI 

At the (conf ig) command prompt, enter the following commands: 

SGOS# (conf ig) forwarding 

SGOS# (conf ig forwarding) path url 

where url is a fully-qualified URL, including the filename, where the installable list is located. 

SGOS# (conf ig forwarding) exit 
SGOS# (conf ig) load forwarding 

To Create Forwarding Settings on the ProxySG through the CLI 

1. At the (conf ig) command prompt, enter the following commands to create an inline set of 

commands. You can use any of the forwarding directives, but host affinity and load balancing are 
mutually exclusive. The procedure below demonstrate the creation of an inline forwarding 
configuration, using the non-SSL host affinity method: 
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SGOS# (config) inline forwarding eof 

fwd_host test 10.25.36.47 default-schemes 
host_af f inity method client-ip-address 
host_af f inity timeout 45 
eof 
ok 



where: 



forwarding 


Identifies the kind of inline settings you are creating. 


eof 


Specifies the marker that tells the CLI that you are beginning or ending the set of 
commands. You can use any characters as the end-of-file marker. 



The limitation to using the inline command to create a configuration is that you cannot create 
mistakes except on the current line. If you find an error farther back than that, you must start over 
after exiting the current file. 

2. View the results. 

SGOS# (config) show forwarding 

download-via- forwarding : enabled 

Connection attempts to forwarding hosts fail: closed. 

Forwarding Groups: (* = host unresolved) 

Group : techpubs 

test3 10.25.36.47 http=80 ftp=21 rtsp=554 

Individual Hosts: (* = host unresolved) 

No individual hosts defined. 

Load balancing hash: domain 
Load balancing method: no 

Host affinity method (non-SSL) : client-ip-address 
Host affinity method (SSL) : client-ip-address 
Host affinity timeout: 45 minutes 

To Delete Forwarding Settings on the ProxySG through the CLI 

From the (config) prompt, enter the following commands to delete a host, a group, or all hosts and 
groups from the forwarding configuration: 

SGOS# (config) forwarding 

SGOS# (config forwarding) delete {all | group group_name | host host_alias } 



Note: Any host or group in the default sequence is considered in use by policy. As a result, if 

you try to delete a host or group while it is in the default sequence, you receive an error 
message. You must remove the host /group from the sequence first, then delete. 
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SOCKS Gateway Configuration 

The ProxySG implementation of SOCKS includes the following: 

□ A SOCKS proxy server that supports both SOCKSv4/4a and SOCKSv5, running on the ProxySG. 

□ Support for forwarding through SOCKS gateways. 

To configure a SOCKS proxy server on the ProxySG, see "Configuring a SOCKS Proxy" on page 223. To 
use SOCKS gateways when forwarding, continue with the next section. 



Note: SOCKS gateway aliases cannot be CPL keywords, such as no, default, forward, or 

socks_gateways. 



Using SOCKS Gateways 

SOCKS servers provide application level firewall protection for an enterprise. The SOCKS protocol 
provides generic way to proxy HTTP. 

SOCKS gateways, like ICP and forwarding, can use installable lists for configuration. You can 
configure the installable list using directives. You can also use the CLI to create a SOCKS gateways 
configuration. 

Using the CLI to Create SOCKS Gateways Settings 

If you prefer, you can use SOCKS gateways CLI commands, instead of an installable list, to create 
SOCKS gateways settings. For information about using an installable list, see "Using SOCKS 
Gateways Configuration Directives to Create an Installable List" on page 871. 

To Create a SOCKS Gateways Host through the CLI 

1. At the (config) command prompt, enter the following commands: 

SGOS# (config) socks -gateways 

SGOS# (config socks -gateways) create gateway_alias gateway_host SOCKS_port 
[version {=4 | =5} ] [user=username {password=password | encrypted-password= 
encrypted-password ] [request-compression {=yes | =no}] 

where: 



gateway_alias 




A name, meaningful to you 


gateway_host 




The IP address or the host name of the gateway 
where traffic is directed. The host name must 
DNS resolve. 


SOCKS_port 




The port number of the SOCKS gateway. 


version 


=4 | =5 


The version that SOCKS gateways can support. 
(SOCKS v5 is recommended, if you have a 
choice). If no version is configured, the default 
is version 4. 
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user 


=username 


(Optional, and only if you use v5) The 
username of the user on the SOCKS gateway. 
The username already must exist on the 
gateway. If you use user=, you must also use 
passwords 


password 

or 

encrypted- pas sword 


=password 

or 

=encrypted- 

password 


(Optional, and only if you use v5) The plaintext 
password or encrypted password of the user 
on the SOCKS gateway. The password must 
match the gateway's information. If you use 
user=, you must also use passwords 
The password or encrypted password can be 
up to 64 bytes long. Passwords that include 
spaces must be within quotes. 

Note that the password in plaintext is a 
security risk. 


request -compress ion 


=yes | =no 


(Optional, and only if you use v5) Enable or 
disable SOCKS compression. The default is no. 

To use SOCKS compression, you must enable 
compression on a SOCKS gateway, enable an 
Endpoint Mapper proxy, and create policy to 
forward TCP traffic through the SOCKS 
gateway. For more information, see 
"Understanding SOCKS Compression" on 
page 223 



2 . 



3. 



where 



failure-mode 


open | closed 


If the health checks fail, open specifies that the 
connection be attempted without use of any 
SOCKS gateway (whether to an origin content 
server or a forwarding target); closed specifies 
that the connection be aborted. 


delete 


all | gateway 
gateway_alias 


Deletes all SOCKS gateways (delete all) or a 
specific SOCKS gateway (delete gateway 
gateway alias). 


path 


url 


(Optional) Specifies the download path to use if 
you download SOCKS-gateways settings 
through directives. 



Repeat for step 1 for each gateway you want to create. The failure-mode command applies to all 
SOCKS gateways configured on the system. The default failure mode can be overridden using 
policy. 

Complete the configuration by entering the following commands as necessary: 

SGOS#(config socks -gateways) failure-mode {open | closed} 

SGOS# (config socks -gateways) delete {all | gateway gateway_alias } 

SGOS#(config socks -gateways) path url 
SGOS# (config socks -gateways) no path 
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no 


path 


Clears the network path URL to download 






SOCKS gateway settings. 



4. View the results. 

SGOS#(config socks-gateways) view 

SOCKS Gateways: (* = gateway unresolved) 

Sec_Appl 10.25.36.47 1080 V5 



Editing a SOCKS Gateways Host 

Once you have created a SOCKS gateways host, you can edit the settings. 



To Edit the Settings of a SOCKS Gateways Host through the CLI 



At the (config) command prompt, enter the following commands: 

SGOS# (config) socks-gateways 

SGOS# (config socks-gateways) edit gateway_alias 

SGOS# (config socks-gateways gateway_alias ) host gateway_host 
SGOS# (config socks-gateways gateway_alias 
SGOS# (config socks-gateways gateway_alias 
encrypted-password encrypted-password } 

SGOS# (config socks-gateways gateway_alias 
SGOS# (config socks-gateways gateway_alias 
SGOS# (config socks-gateways gateway_alias 
SGOS# (config socks-gateways gateway_alias 
disable 



no password | user 
{password password / 

port socks_port 
user username 
version 4 | 5 

request -compress ion enable 



where: 



host 


gateway host 


Changes the host name. 


no 


password | user 


Optional, and only if you use version 5. Deletes the 
version 5 password or username. 


password 

or 

encrypted- 

password 


password 

or 

encrypted- 

password 


Optional, and only if you use version 5. Changes the 
version 5 plaintext password or encrypted password. 
(Passwords in plaintext are a security risk.) Note that the 
password or encrypted password can be up to 64 bytes 
long. Passwords that include spaces must be within 
quotes. 


port 


socks_port 


Changes the SOCKS port. 


user 


username 


Optional, and only if you use version 5. Changes the 
version 5 username. 


version 


4 | 5 


Changes the SOCKS version. 



869 



Blue Coat Proxy SG Configuration and Management Guide 



request- 


enable | disable 


(Optional, and only if you use v5) Enable or disable 


compression 




SOCKS compression. The default is disable. 






To use SOCKS compression, you must enable 
compression on a SOCKS gateway, enable an Endpoint 
Mapper proxy, and create policy to forward TCP traffic 
through the SOCKS gateway. For more information, see 
"Understanding SOCKS Compression" on page 223 



Example 

SGOS# (config) socks -gateways 

SGOS# (config socks -gateways) edit testsocks 
SGOS# (config socks -gateways testsocks) port 23 
ok 

SGOS# (config socks -gateways testsocks) version 5 
ok 

SGOS# (config socks -gateways testsocks) exit 
SGOS# (config socks-gateways) exit 
SGOS# (config) 

Creating a Default Sequence 

A default sequence defines the order in which SOCKS gateways hosts are used. Only one default 
sequence is allowed. All members must be pre-existing hosts, and no member can be in the group 
more than once. 



Note: The default sequence replaces the deprecated default and backup settings. The default 

sequence (if present) is applied only if no applicable forwarding gesture is in policy. 



A default failover sequence allow healthy hosts to take over for an unhealthy host (one that is failing 
its DNS Resolution or its health check). The sequence specifies the order of failover, with the second 
host taking over for the first host, the third taking over for the second, and so on. 

If all hosts are unhealthy, the operation fails either open or closed, depending upon your settings. 

This configuration is generally created and managed through policy. If no SOCKS-gateways policy 
applies, you can create a default sequence through the CLI. This single default sequence consists of a 
single default host (or group) plus one or more hosts to use if the preceding ones are unhealthy. 

The syntax is 

sequence alias_name alias_name 

where alias_name is a space-separated list of one or more SOCKS gateways. 

To create a default failover sequence, enter the following commands from the (config) prompt: 
SGOS# (config) socks-gateways 

SGOS# (config socks-gateways) sequence add gateway-alias 

SGOS# (config socks-gateways) sequence promote | demote gateway-alias 

SGOS# (config socks-gateways) sequence clear | remove gateway-alias 
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where: 



sequence 


add 


Adds an alias to the end of the default fail-over sequence 




clear 


Clears the default fail-over sequence 




demote 


Demotes an alias one place towards the end of the default fail-over 
sequence 




promote 


Promotes an alias one place towards the start of the default fail-over 
sequence 




remove 


Removes an alias from the default fail-over sequence. 



Using SOCKS Gateways Configuration Directives to Create an Installable List 

To configure a SOCKS gateway you must create an installable list and load it on the ProxySG. 
Alternately, you can use the CLI to configure SOCKS gateways. To use the CLI, see "Using the CLI to 
Create SOCKS Gateways Settings" on page 867. 

For information on installing the file itself, see "Creating a SOCKS Gateway Installable List” on 
page 873. 

The SOCKS gateways configuration includes SOCKS directives that: 

□ Names the SOCKS gateway hosts 

□ Specifies the SOCKS version 

□ (Optional, if using Version 5) Specifies user name and password 

Available directives are described in the table below. 

Table 19.3: SOCKS Gateway Directives 



Directive 


Meaning 


gateway 


Specifies the gateway alias and name, SOCKS port, version supported, 
usernames and password. 


socks_fail 


In case connections cannot be made, specifies whether to abort the 
connection attempt or to connect to the origin content server 


sequence 


Specifies the order in which hosts should be used for failover. 



Syntax for the SOCKS directives are: 

gateway gateway_alias gateway_host SOCKS port [version={4 | 5 [user= username 
{password=password / encrypted-password=encrypted-password}] 
[request-compression= {yes | no}]}] 

socks_fail {open | closed} 
sequence gateway_name 



871 



Blue Coat Proxy SG Configuration and Management Guide 



where: 



gateway 




Configures the SOCKS gateway host. 




gateway_alias 


A meaningful name that is used for policy rules. 




gateway_name 


The IP address or host name of the gateway where 
traffic is directed. The host name must DNS resolve. 




SOCKS -port 


The port number of the SOCKS gateway. 




version={4 | 5} 


The version that SOCKS gateways can support. 




user= username 


(Optional, if you use v5) The username of the user on 
the SOCKS gateway. It already must exist on the 
gateway. 




password =password 
or 

encrypted- 
password 
encrypt ed-pass 
word 


The plaintext password or encrypted password of the 
user on the SOCKS gateway. It must match the 
gateway's information. (Passwords in plaintext are a 
security risk.) 

Note that the password or encrypted password can be 
up to 64 bytes long. Passwords that include spaces 
must be within quotes The password of the user on 
the SOCKS gateway. It must match the gateway's 
information. 


request - 
compression 


request - 

compression =yes 
| =no 


(Optional, if you use v5) Enables or disables SOCKS 
compression. The default is no. 

To use SOCKS compression, you must enable 
compression on a SOCKS gateway, enable an 
Endpoint Mapper proxy, and create policy to forward 
TCP traffic through the SOCKS gateway. For more 
information, see "Understanding SOCKS 
Compression" on page 223 


socks_fail 


{open | closed} 


If health checks fail, socks gateway .fail open 
specifies that the connection be attempted without 
using a SOCKS gateway (for example, go to the 
original server or forwarding target); 
socks gateway .fail closed specifies that the 
connection be aborted. The default is closed. Fail 
open is a security risk, and fail closed is the default if 
no setting is specified. This setting can be overridden 
by policy, (using the 

forward, fail open (yes | no) property). 


sequence 


gateway name 


Specifies the order in which hosts should be used for 
failover. 



Example 

gateway Sec_Appl 10.25.36.47 1022 version=5 user =username password=password 
socks_gateway . f ail_open no 
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Important: The username and password display in clear text if you run the show conf ig 

command. 



A default sequence defines the order in which forwarding hosts are used. Only one default sequence 
is allowed. All members must be pre-existing hosts and groups, and no member can be in the 
sequence more than once. 



Note: The default sequence replaces the deprecated default and backup settings. The default 

sequence (if present) is applied only if no applicable forwarding gesture is in policy. 



A default failover sequence works by allowing healthy hosts to take over for an unhealthy host (one 
that is failing its DNS Resolution or its health check). The sequence specifies the order of failover, with 
the second host taking over for the first host, the third taking over for the second, and so on). 

If all hosts are unhealthy, the operation fails either open or closed, depending upon your settings. 

This configuration is generally created and managed through policy. If no SOCKS-gateways policy 
applies, you can create a default sequence through the CLI. This single default sequence consists of a 
single default host (or group) plus one or more hosts to use if the preceding ones are unhealthy. 

The syntax is 

sequence gateway_name gateway_name 

where gateway_name is a space-separated list of one or more SOCKS gateway aliases. 

Example 

sequence gateway_alias 

Creating a SOCKS Gateway Installable List 

You can create and install the SOCKS gateway installable list with the following methods: 

□ Use the ProxySG Text Editor, which allows you to enter directives (or copy and paste the contents 
of an already-created file) directly onto the ProxySG. 

□ Create a local file on your local system; the ProxySG can browse to the file and install it. 

□ Use a remote URL, where you place an already-created file on an FTP or HTTP server to be 
downloaded to the ProxySG. 

When the SOCKS gateway installable list is created, it overwrites any previous SOCKS gateway 
configurations on the ProxySG. The installable list remains in effect until it is overwritten by another 
installable list; it can be modified or overwritten using CLI commands. 



Note: During the time that a SOCKS gateway installable list is being compiled and installed, 

forwarding is not available. Any transactions that come into the ProxySG during this time 
are not forwarded properly and are denied. 
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Installation of SOCKS gateways installable-list configuration should be done outside peak traffic 
times. 

To Create a SOCKS Gateways Installable List through the Management Console 

1. Select Configuration>Forwarding>SOCKS Gateways. 

SOCKS Gateways 

• I dent protocol (required for SOCKS): 

Machine id: 







Install SOCKS Gateway File from: 


Remote URL v [ Install ] 






Gateway Settings 


View the current Gateway Settings 





Apply 




Cancel 


ir 


Help 



Figure 19-5: Selecting the SOCKS Gateways Tab 

2. If you use a SOCKS gateway server for the primary or alternate forwarding gateway, you must 
specify the ProxySG ID for the Identification (Ident) protocol used by the SOCKS gateway in 
SOCKS' server handshakes. The default is bluecoat systems. 

3. From the drop-down list, select the method used to install the SOCKS gateway configuration; 
click Install. 

• Remote URL: 

Enter the fully-qualified URL, including the filename, where the configuration is located. To 
view the file before installing it, click View. Click Install. Examine the installation status that 
displays; click OK. 

• Local File: 

Click Browse to bring up the Local File Browse window. Browse for the file on the local 
system. Click Install. When the installation is complete, a results window opens. View the 
results, close the window, click Close. 

• Text Editor: 

The current configuration is displayed in installable list format. You can customize it or delete 
it and create your own. Click Install. When the installation is complete, a results window 
opens. View the results, close the window, click Close. 

4. Click Apply. 
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To Specify the SOCKS Gateway Machine ID through the CLI 



Note: This is an optional command. The default is Blue Coat Systems. 



At the conf ig command prompt, enter the following command: 

SGOS# (config) socks -machine- id machine_ID 

To Create a Remote SOCKS Gateways Installable List through the CLI 

At the (config) prompt, enter the following commands: 

SGOS# (config) socks -gateways 

SGOS# (config socks -gateways) path url 

where url is a fully-qualified URL, including the filename, where the configuration is located. 

SGOS# (conf ig) socks -gateways) exit 
SGOS# (config) load socks-gateways 

Tip for SOCKS Configuration 

By default, SOCKS treats all incoming requests destined to port 80 as HTTP, allowing the usual HTTP 
policy to be done on them, including ICAP scanning. If the SOCKS connection is being made to a 
server on another port, you should write policy on the ProxySG to match on the server host and port 
and specify that it is HTTP using SOCKS. 

Internet Caching Protocol (ICP) Configuration 

ICP is a communication protocol for caches. It allows a cache (not necessarily a ProxySG) to query 
other caches for an object, without actually requesting the object. By using ICP, the cache can 
determine if the object is available from a neighboring cache, and which cache provides the fastest 
response. 



Note: The ProxySG (assuming ICP is configured) does ICP queries only if no forwarding host or 

SOCKS gateway is identified as an upstream target. If ICP is used by the ProxySG, it 
prompts other cache devices for the item, and upon a positive response re-directs the 
upstream request to that cache device instead of the content origin server. 



Only use ICP if you have ICP hosts available or if you want the ProxySG to support requests from 
other ICP hosts. 

By default, the ICP protocol requires the requesting host to wait up to two seconds for all ICP hosts to 
respond to the request for an object (the time is configurable). 

If the ICP service is configured and running, the service is used if no forwarding or SOCKS gateway 
target was specified. In other words, the policy rule icp (yes ) is the default, assuming that the ICP 
service is available. You can disable ICP with the policy rule icp (no) to control ICP queries for 
requests. 
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Configuring ICP 

An ICP hierarchy is comprised of a group of caches, with defined parent and sibling relationships. A 
cache parent is one that can return the object if it is in the cache, or request the object from the source 
on behalf of the requester if the object is not in the cache. A cache sibling is a device that can only 
return the object if it is in the cache. One cache acting as a parent can also act as a sibling to other cache 
devices. 

□ When an object is not cached, the cache device sends an ICP query to its neighbors (parents and 
siblings) to see if any of its peers holds the object. 

□ Each neighbor that holds the requested object returns an ICP_HIT reply. 

□ Each neighbor that does not hold the object returns an ICP_MISS reply. 

Based on the responses, the cache can determine where to request the object: from one of its neighbors 
or from the source. If an icp hit reply is received, the request is sent to the host that returned the first 
reply. If no ICP HIT reply is received, the request is forwarded to the first parent that replied. If no 
parents respond or are configured, the request is made directly to the source. 

Using ICP Configuration Directives to Create an Installable List 

To configure ICP you must create an installable list and load it on the ProxySG. The ICP protocol 
contains a number of directives, commands used to create a list that can be installed on the ProxySG. 

For information on installing the file itself, see "Creating an ICP Installable List” on page 880. 

The ICP configuration includes directives that: 

□ Name the ICP hosts 



□ Restrict ICP access to only these hosts 

Available directives are listed in Table 19.4. 
Table 19.4: ICP Directives 



Directive 


Meaning 


Where used 


icp_host 


The icp host directive describes cache peers in 
the hierarchy. There should be one entry for each 
ProxySG you want to use. 


Names the ICP hosts. See 
"Naming the IP Hosts" on 
page 877. 


icp_access_ 

domain 


The icp_access_domain directive is used to 
control which ICP queries are accepted. The 
icp access domain directive requires a reverse 
DNS lookup of each ICP query to validate the IP 
address. 


Restricts access. See "Restricting 
Access" on page 878. 


icp_access_ip 


The icp access ip directive works like the 
icp access domain command, except you can 
specify an IP address and subnet mask rather than 
a domain. 


Restricts access. 

See "Restricting Access" on 
page 878. 


icp_port 


The icp port directive sets the port the ProxySG 
uses to listen for ICP requests. The default port is 
3130. If you set the port to 0, ICP is disabled. 


Connects to other ICP hosts. See 
"Connecting to other ICP 
Hosts" on page 879. 
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Table 19.4: ICP Directives (Continued) 



Directive 


Meaning 


Where used 


neighbor timeout 


The neighbor timeout directive sets the 
number of seconds the ProxySG waits for ICP 
replies. When the cache device sends an ICP 
request, it waits for all hosts to reply or for the 
neighbor timeout to expire. The default 
timeout is two seconds. 


Connects to other ICP hosts. See 
"Connecting to other ICP 
Hosts" on page 879. 


icp_failc ount 


The icp failcount directive sets the number of 
consecutive failures the cache device can receive 
before considering the ICP host as failed. By 
default, the ICP failure count is set to 20. Each time 
a request fails, the failure count is incremented. 
When a request succeeds, the failure count is reset 
to zero. 


Connects to other ICP hosts. See 
"Connecting to other ICP 
Hosts" on page 879. 


http failcount 


The http failcount directive sets the number 
of consecutive failures the cache device can receive 
before considering the HTTP host as failed. By 
default, the HTTP failure count is set to five. The 
failure count increments each time a request fails. 
When a request succeeds, the failure count is reset 
to zero. When an HTTP host fails, the cache device 
waits five minutes before attempting to use it again 
as a forwarding target. If the next request fails, the 
cache device continues to wait five minutes 
between attempts until the cache becomes 
available. 


Connects to other ICP hosts. See 
"Connecting to other ICP 
Hosts" on page 879. 


host_fail_notify 


The host fail notify directive tells the cache 
device to send event notification e-mail when a 
connect fails persistently. 


Connects to other ICP hosts. See 
"Connecting to other ICP 
Hosts" on page 879. 


host recover 
notify 


The host recover notify directive tells the 
cache device to send event notification e-mail 
when a failed host recovers. 


Connects to other ICP hosts. See 
"Connecting to other ICP 
Hosts" on page 879. 



Naming the IP Hosts 

The icp_host directive describes peers in the hierarchy. One entry is required for each ProxySG you 
want to use. 

icp_host hostname peertype HTTPport ICPport [default | backup | feeder] 



where: 



hostname 




The host name of the ProxySG. 


peertype 


{parent | 
sibling} 


Relationship of the ProxySG to the cache device you are 
configuring. 


HTTPport 




TCP port where the ProxySG accepts HTTP requests. The common 
HTTP port is 80 or 8080. 
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ICPport 




UDP port where the ProxySG accepts ICP requests. The common 
ICP port is 3130. 


default 




If specified, designates a ProxySG host parent to be the default ICP 
parent. If no ICP reply is received, all requests are forwarded to the 
default parent. 


backup 




If specified, designates the cache device host parent to be the 
backup default ICP parent. If the default parent is not available, the 
cache device uses the backup default parent. 


feeder 




If specified, designates the ProxySG host sibling as a feeder-type 
host, using ICP request loops to populate the ProxySG. 



The following are sample icp host directives that can be entered into the ICP configuration: 



; Define 
icp_host 
icp_host 
icp_host 
icp_host 
icp_host 



ICP parent and sibling hosts. 



cml . bluecoat . com 
cm2 .bluecoat . com 
cm3 .bluecoat . com 
cm4 .bluecoat . com 
cm5 .bluecoat . com 



parent 8080 3130 default 
sibling 8080 3130 
sibling 8080 3130 
sibling 8080 3130 
parent 8080 3130 



Restricting Access 

You can restrict access to ProxySG acting as caches by other ICP hosts using the icp_access_domain 
and icp_access_ip directives. By default, when ICP is configured, all ICP hosts are allowed access. 
You should deny access to all domains other than the ICP hosts you want to use. 

icp_access_domain Directive 

The icp_access_domain directive defines which hosts can request objects from the Web cache using 
ICP. The default action is to allow all requests. When you use icp_access_domain, each ICP query 
requires a reverse DNS lookup to validate the IP address. Depending on the number of ICP requests, 
these lookups can consume ProxySG resources. 

icp_access_domain {allow | deny} domain 



where: 



allow | 
deny 


Allows or denies ICP queries from neighbors that match the domain specification. 


domain 


The domain to match. All ICP queries from neighbors that match the specified 
domain are handled by the host. The special domain of all defines the default action 
when there is no domain match. 



The following are sample icp_access_domain directives to be entered into the ICP configuration: 
; allow ICP access to this Blue Coat Systems ProxySG Appliance from the 
; bluecoat.com domain 
icp_access_domain allow bluecoat.com 
icp_access_domain deny all 

; the deny all option should always be specified to deny all other 
; domains 
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icp_access_ip Directive 

The icp_access_ip directive works like the icp_access_domain command, except you can specify 
an IP address and subnet mask rather than a domain. The following describes the parameters for the 
icp_access_ip command: 

icp_access_ip {allow | deny} subnet mask 



where: 



allow | deny 


Allow or deny ICP queries from neighbors that match the address 
specification. 


address/ subnet 
mask 


The address and subnet mask to match. All ICP queries that match the 
specified address are handled by the ICP host. The special address of 0 . 0 . 0 . 0 
defines the default action when there is no address match. 



The following are sample icp access ip directives to be entered into the ICP configuration: 

; allow ICP access to this Blue Coat Systems ProxySG Appliance from the local 
subnet 

icp_access_ip allow 192.168.10.0/255.255.255.0 
icp_access_ip deny 10.25.36.47 

; the deny all option should always be specified to deny all other domains 

Connecting to other ICP Hosts 

In addition to the ICP directives described in the sections above, you can specify the following 
directives in the ICP configuration: 

icp_port 0 
neighbor_timeout 2 
icp_f ailcount 20 
http_f ail count 5 
host_f ail_notify on 
host_recover_notify on 



where: 



icp_port 


The default port is 3130. If you set the port to 0, ICP is disabled. 


neighbor timeout 


When the cache device sends an ICP request, it waits for all hosts to reply or 
for the neighbor timeout to expire. The default timeout is two seconds. 


http failcount 


By default, the HTTP failure count is set to five. The failure count increments 
each time a request fails. When a request succeeds, the failure count resets to 
zero. When an HTTP host fails, the cache device waits five minutes before 
attempting to use it again as a forwarding target. 


icp failcount 


By default, the ICP failure count is set to 20. Each time a request fails, the 
failure count is incremented. When a request succeeds, the failure count is 
reset to zero. 


host_fail_notify 


on tells the cache to send event notification e-mail when a connect fails 
persistently; off disables this setting. 


host recover 
notify 


on tells the cache to send event notification e-mail when a failed host 
recovers; off disables this setting. 
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Creating an ICP Installable List 

You can create the ICP installable list with the following methods: 

□ Use the ProxySG Text Editor, which allows you to enter directives (or copy and paste the contents 
of an already-created file) directly onto the ProxySG. 

□ Create a local file on your local system; the ProxySG can browse to the file and install it. 

□ Use a remote URL, where you place an already-created file on an FTP or HTTP server to be 
downloaded to the ProxySG. 

□ Use the CLI inline command. 

When the ICP installable list is created and installed, it overwrites any ICP settings on the ProxySG. 

To Create an ICP Installable List through the Management Console 
1. Select Configuration>Forwarding>ICP. 



ICP 

Install ICP Settings 

Install ICP Settings from: 



Remote URL v 



Install 



View ICP Settings 



ICP Settings 



Source 



View the current ICP Settings 

View source for the current ICP Settings 













Apply 


II 


Cancel 


II 


Help 



Figure 19-6: Selecting the ICP Download Method 

2. From the drop-down list, select the method you want to use to install the ICP configuration; then 
click Install. 

• Remote URL: 

Enter the fully-qualified URL, including the filename, where the configuration is located. To 
view the file before installing it, click View. Click Install. Examine the installation status that 
displays; click OK. 

• Local File: 

Click Browse to bring up the Local File Browse window. Browse for the file on the local 
system. Click Install. When the installation is complete, a results window opens. View the 
results, close the window, click Close. 

• Text Editor: 
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The current configuration is displayed in installable list format. You can customize it or delete 
it and create your own. Click Install. When the installation is complete, a results window 
opens. View the results, close the window, click Close. 

3. Click Apply. 

To Create a Remote ICP Installable List through the CLI 

At the (config) command prompt, enter the following commands: 

SGOS# (config) icp path url 

where url is a fully -qualified URL, including the filename, where the configuration is 
located. 

SGOS# (config) load icp-settings 

To Create ICP Settings on the ProxySG through the CLI 

From the (config) prompt, enter the following commands to create an inline set of commands. You 
can use any of the ICP directives, not just the ones displayed here. 

SGOS# (config) inline icp-settings eof 

icp_port 0 
neighbor_timeout 2 
icp_f ailcount 20 
http_f ail count 5 
eof 
ok 



where: 



icp-settings 


Identifies the type of inline settings you are creating. 


eof 


Specifies the marker that tells the CLI that you are using to begin and end the set 
of commands. You can use any characters as the end-of-file marker. 



The drawback to using the inline command to create a configuration is that you cannot correct 
mistakes except on the current line. If you find an error farther back than that, you must start over 
after exiting the current file. 

Enabling ICP 

ICP must be running and at least one forwarding host configured before ICP can be used in the 
ProxySG environment. ICP can be enabled or disabled through the policy rule icp . The default is 
icp (yes) . You can disable ICP with the policy rule icp (no) to control ICP queries for requests. 

Using Policy to Manage Forwarding 

Once ICP, forwarding, and the SOCKS gateways are configured, you can use policy to create and 
manage forwarding rules. Forwarding, ICP, and SOCKS gateway rules should go in the <Forward> 
layer of your Forwarding Policy file or your VPM Policy file (if you use the VPM). 
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Note: Because the contents of the Forward policy file are overwritten by the CLI 

restore-sgos2-config or restore-cacheos4-config commands, you should back up 
the file before using them. 



The separate <Forward> layer (and server _ur I triggers in place of url triggers) is provided because the 
url can undergo URL rewrites before the request is fetched. This rewritten URL is accessed as 
server _url and decisions about upstream connections are based on that, requiring a separate layer. All 
policy commands allowed in the <Forward> layer are described in Table 19.5. 



Table 19.5: Forwarding Conditions, Properties, Actions, and Definitions 



Forwarding 


Description 


Conditions 


client_address= 


Tests the IP address of the client. Can also be used in 
<Exception> and <Proxy> layers. 


client . host= 


Tests the hostname of the client (obtained through 
RDNS). Can also be used in <Admin>, <Proxy>, and 
<Exception> layers. 


client . host . has name= 


Tests the status of the RDNS performed to determine 
client . host. Can also be used in <Admin>, 
<Proxy>, and <Exception> layers. 


client .protocol= 


Tests true if the client transport protocol matches the 
specification. Can also be used in <Exception> and 
< Proxy > layers. 


date [ .utc] = 


Tests true if the current time is within the 
startdate..enddate range, inclusive. Can be used in all 
layers. 


day= 


Tests if the day of the month is in the specified range or 
an exact match. Can be used in all layers. 


has client= 


has client=is used to test whether or not the current 
transaction has a client. This can be used to guard 
triggers that depend on client identity. 


hour [ . utc] = 


Tests if the time of day is in the specified range or an 
exact match. Can be used in all layers. 


im. client= 


Tests the type of IM client in use. Can also be used in 
<Proxy>, <Exception>, and <Cache> layers. 


im . message . ref lected= 


Tests whether IM reflection occurred. Can also be used 
in <Proxy> and <Cache> layers. 


minute [ . utc] =month [ . utc] = 


Tests if the minute of the hour is in the specified range 
or an exact match. Can be used in all layers. 
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Table 19.5: Forwarding Conditions, Properties, Actions, and Definitions (Continued) 



Forwarding 


Description 


proxy . address= 


Tests the IP address of the network interface card (NIC) 
on which the request arrives. Can also be used in 
<Admin> and <Proxy> layers. 


proxy . card= 


Tests the ordinal number of the network interface card 
(NIC) used by a request. Can also be used in <Admin> 
and < Proxy > layers. 


proxy . port= 


Tests if the IP port used by a request is within the 
specified range or an exact match. Can also be used in 
<Admin> and <Proxy> layers. 


server url [ . case sensitive | . no 
lookup] = 


Tests if a portion of the requested URL exactly matches 
the specified pattern. 


server url.address= 


Tests if the host IP address of the requested URL 
matches the specified IP address, IP subnet, or subnet 
definition. 


server url . domain [. case sensitive] 
[ ,no_lookup] = 


Tests if the requested URL, including the domain-suffix 
portion, matches the specified pattern. 


server url . extension [. case sensitive] 


Tests if the filename extension at the end of the path 
matches the specified string. 


server url. host. has name= 


Tests whether the server URL has a resolved DNS 
hostname. 


server url . host [ . exact | . substring | 
.prefix| .suffix| .regex] [ . no_lookup] = 


Tests if the host component of the requested URL 
matches the IP address or domain name. 


server url. host. is numeric= 


This is true if the URL host was specified as an IP 
address. 


server url.host.no name= 


This is true if no domain name can be found for the 
URL host. 


server url . host . regex= 


Tests if the specified regular expression matches a 
substring of the domain name component of the 
requested URL. 


server url . is absolute= 


Tests whether the server URL is expressed in absolute 
form. 


server url . path [ . exact | . substring | 
.prefix| .suffix| .regex] 

[ . case_sensitive] = 


Tests if a prefix of the complete path component of the 
requested URL, as well as any query component, 
matches the specified string. 


server url . path . regex= 


Tests if the regex matches a substring of the path 
component of the request URL. 
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Table 19.5: Forwarding Conditions, Properties, Actions, and Definitions (Continued) 



Forwarding 


Description 


server url.port= 


Tests if the port number of the requested URL is within 
the specified range or an exact match. 


server url . query . regex= 


Tests if the regex matches a substring of the query string 
component of the request URL. 


server url . regex= 


Tests if the requested URL matches the specified 
pattern. 


server url . scheme= 


Tests if the scheme of the requested URL matches the 
specified string. 


socks= 


This condition is true whenever the session for the 
current transaction involves SOCKS to the client. 


socks . version= 


Switches between SOCKS 4/4a and 5. Can also be used 
in <Exception> and <Proxy> layers. 


streaming . client= 


yes | no. Tests the user agent of a Windows, Real 
Media, or QuickTime player. 


time [ .utc] = 


Tests if the time of day is in the specified range or an 
exact match. Can be used in all layers. 


tunnel ed= 


yes | no. Tests TCP tunneled requests, HTTP 
CONNECT requests, and unaccelerated SOCKS 
requests 


weekday [ .utc] = 


Tests if the day of the week is in the specified range or 
an exact match. Can be used in all layers. 


year [ .utc] = 


Tests if the year is in the specified range or an exact 
match. Can be used in all layers. 


Properties 




access_server ( ) 


Determines whether the client can receive streaming 
content directly from the OCS. Set to no to serve only 
cached content. 


ftp . transport ( ) 


Determines the upstream transport mechanism. 
This setting is not definitive. It depends on the 
capabilities of the selected forwarding host. 


forward ( ) 


Determines forwarding behavior. 

There is a box-wide configuration setting 
(conf ig>forwarding>failure-mode) for the 
forward failure mode. The optional specific settings can 
be used to override the default. 
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Table 19.5: Forwarding Conditions, Properties, Actions, and Definitions (Continued) 



Forwarding 


Description 


forward. fail open ( ) 


Controls whether the ProxySG terminates or continues 
to process the request if the specified forwarding host 
or any designated backup or default cannot be 
contacted. 


http . refresh . recv . timeout ( ) 


Sets the socket timeout for receiving bytes from the 
upstream host when performing refreshes. Can also be 
used in < Cache > layers. 


http . server . connect_attempts ( ) 


Sets the number of attempts to connect performed 
per-address when connecting to the upstream host. 


http . server . recv . timeout ( ) 


Sets the socket timeout for receiving bytes from the 
upstream host. Can also be used in < Proxy > layers. 


icp ( ) 


Determines when to consult ICP. The default is yes if 
ICP hosts are configured and if no forwarding host or 
SOCKS gateway is identified as an upstream target. 


im. transport ( ) 


Sets the type of upstream connection to make for IM 
traffic. 


integrate_new_hosts ( ) 


Determines whether to add new host addresses to 
health checks and load balancing. The default is no. If it 
is set to yes, any new host addresses encountered 
during DNS resolution of forwarding hosts are added 
to health checks and load balancing. 


ref lect_ip ( ) 


Determines how the client IP address is presented to the 
origin server for explicitly proxied requests. Can also be 
used in < Proxy > layers. 


socks_gateway ( ) 


The socks_gateway ( ) property determines the 
gateway and the behavior of the request if the gateway 
cannot be contacted. 

There is a box-wide configuration setting for the SOCKS 
failure mode. The optional specific settings can be used 
to override the default. 


socks gateway. fail open ( ) 


Controls whether the ProxySG terminates or continues 
to process the request if the specified SOCKS gateway 
or any designated backup or default cannot be 
contacted. 


streaming . transport ( ) 


Determines the upstream transport mechanism. This 
setting is not definitive. The ability to use 
streaming . transport ( ) depends on the 
capabilities of the selected forwarding host. 
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Table 19.5: Forwarding Conditions, Properties, Actions, and Definitions (Continued) 



Forwarding 


Description 


trace . request ( ) 


Determines whether detailed trace output is generated 
for the current request. The default value is no, which 
produces no output 


trace . rules ( ) 


Determines whether trace output is generated that 
shows each policy rule that fired. The default value of no 
suppresses output. 


trace . destination ( ) 


Used to change the default path to the trace output file. 
By default, policy evaluation trace output is written to 
an object in the cache accessible using a console URL of 
the following form: 

http : / / Proxy SG_ip_address : 8081/Policy/ 
Trace/path 


Actions 




notify email ( ) 


Sends an e-mail notification to the list of recipients 
specified in the Event Log mail configuration. Can be 
used in all layers. 


notify_snmp ( ) 


The SNMP trap is sent when the transaction terminates. 
Can be used in all layers. 


log_message 


Writes the specified string to the ProxySG event log. 


Definitions 




define server url . domain condition 
name 


Binds a user-defined label to a set of domain suffix 
patterns for use in a condition= expression. 
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Access logging allows you to track Web usage for the entire network or specific information on user or 
department usage patterns. These logs and reports can be made available in real-time or on a 
scheduled basis. 



Note: Event logging is not the same as access logging. Event logging allows you to specify the 

types of system events logged, the size of the event log, and to configure Syslog 
monitoring. 



This chapter 

□ "Section 

□ "Section 

□ "Section 

□ "Section 

□ "Section 

□ "Section 
a "Section 

□ "Section 



contains the following topics: 

A: Overview" on page 888 

B: Creating and Editing Log Formats" on page 892 
C: Creating an Access Log Facility" on page 897 
D: Editing an Existing Log Facility" on page 899 
E: Associating a Log Facility with a Protocol" on page 903 
F: Configuring Global Settings" on page 907 
G: Configuring the Upload Client" on page 909 
H: Configuring the Upload Schedule" on page 930 
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Section A: Overview 

The ProxySG can create access logs for the traffic flowing through the system; in fact, each protocol 
can create an access log record at the end of each transaction for that protocol (such as for each HTTP 
request). 



Note: The only data that can be logged in an access log on the ProxySG are the access-log fields 

and the CPL fields (found in Appendix B: "Access Log Formats"). 



These log records can be directed to one or more log facilities, which associates the logs with their 
configured log formats, upload schedules, and other customizable components. In addition, access 
logs can be encrypted and digitally signed prior to upload. 

Data stored in log facilities can be automatically uploaded to a remote location for analysis and 
archive purposes. The uploads can take placing using HTTP, FTP, or one of several proprietary 
protocols. Once uploaded, reporting tools such as Blue Coat Reporter can be used to analyze the log 
files. For information on using Blue Coat Reporter, refer to the Blue Coat Reporter User Guide. 

Understanding Facilities 

A log facility is a separate log that contains a single logical file and supports a single log format. The 
facility contains the file's configuration and upload schedule information as well as other configurable 
information such as how often to rotate (switch to a new log) the logs at the destination, any 
passwords needed, and the point at which the facility can be uploaded. 

Multiple access log facilities are supported in SGOS 4.x, although each access log supports a single log 
format. You can log a single transaction to multiple log facilities through a global configuration setting 
for the protocol that can be modified on a per-transaction basis via policy. 
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Log Facility 



Figure 20-1: Log Facility 



Understanding Protocols and Formats 

The following protocols support configurable access logging: 

□ Endpoint Mapper 

□ FTP 

□ HTTP 

□ HTTPS Forward Proxy 

□ HTTPS Reverse Proxy 

□ ICP 

□ Instant Messaging 

□ Peer-to-peer (P2P) 

□ RealMedia/ QuickTime 

□ SOCKS 

□ SSL 

□ TCP Tunnel 
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□ Telnet 

□ Windows Media 

The ProxySG can create access logs with any one of a number of log formats, and you can create 
additional types using custom or ELFF format strings. The log types supported are: 

□ NCSA common log format 

□ SQUID-compatible format 

□ ELFF (W3C Extended Log File Format) 

□ Custom, using the strings you enter 

□ SmartReporter, an ELFF log format compatible with the SmartFilter Reporter tool 

□ SurfControl, a log format compatible with the SurfControl Reporter tool 

□ Websense, a log format compatible with the Websense Reporter tool 

The log facilities, each containing a single logical file and supporting a single log format, are managed 
by policy (created through VPM or CPL), which specifies the destination log format and log file. 



Terms 

□ Log Facility: A separate log that contains a single logical file and supports a single log format. It 
also contains the file's configuration and upload schedule information as well as other 
configurable information such as how often to rotate (switch to a new log) the logs at the 
destination, any passwords needed, and the point at which the facility can be uploaded. 

□ Encrypted Log: A log is encrypted using an external certificate associated with a private key. 
Encrypted logs can only be decrypted by someone with access to the private key. The private key 
is not accessible to the ProxySG. 

□ Log Format: The type of log that is used: NCSA / Common, SQUID, ELFF, SurfControl, or 
Websense. 

The proprietary log types each have a corresponding pre-defined log format that has been set up 
to produce exactly that type of log (these logs cannot be edited). In addition, a number of other 
ELFF type log formats are also pre-defined (im, main, p2p, ssl, streaming). These can be edited, 
but they start out with a useful set of log fields for logging particular protocols understood by the 
ProxySG. It is also possible to create new log formats of type ELFF or Custom which can contain 
any desired combination of log fields. 

□ Log Tail: The access log tail shows the log entries as they get logged. With high traffic on the 
ProxySG, not all access log entries are necessarily displayed. However, you can view all access log 
information after uploading the log. 

□ NCSA common log format: A log type that contains only basic HTTP access information. 

□ SQUID-compatible format: A log type that was designed for cache statistics. 

□ ELFF -compatible format: A log type defined by the W3C that is general enough to be used with any 
protocol. 
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□ SmartReporter. A proprietary ELFF log type that is compatible with the SmartFilter SmartReporter 
tool. 

□ SurfControl: A proprietary log type that is compatible with the SurfControl reporter tool. The 
SurfControl log format includes fully-qualified usernames when an NTLM realm provides 
authentication. The simple name is used for all other realm types. 

□ Websense: A proprietary log type that is compatible with the Websense reporter tool. 

Enabling or Disabling Access Logging 

You can globally enable or disable access logging. If access logging is disabled, logging is turned off 
for all log objects, even if logging policy exists or logging configurations are set. 

Once globally enabled, connection information is sent to the default log facility for the service. For 
example, HTTP traffic is logged to the main file. 

By default, access logging is disabled on all new systems, but certain protocols are configured to use 
specific logs by default. When access logging is enabled, logging begins immediately for all 
configured protocols. 

To Enable or Disable Access Logging through the Management Console 

1. Select Configuration>Access Logging>General>Default Logging. 

Default Logging Global Settings 

|~~| Enable Access Logging 

r Default Logging Policy: 



Protocol 


Default Log 


Endpoint Mapper 


main (Use for protocols having no s. . . 


/V 


FTP 


main (Use for protocols having no s. . . 




HTTP 


main (Use for protocols having no s. . . 




ICP 


<none> 




Instant Messaging 


im (Use for IM protocols) 




TCP Tunnel 


main (Use for protocols having no s. . . 




Telnet 


main (Use for protocols having no s. . . 




Windows Media 


streaming (Use for streaming proto. . . 




rw» n^. 







Figure 20-2: Enabling Access Logging 

2. Select Enable to enable access logging or deselect it to disable access logging. 

3. Click Apply. 

To Enable or Disable Access Logging through the CLI 

From the (config) command prompt, enter the following commands: 

SGOS# (config) access-log 

SGOS# (config access-log) enable | disable 
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Section B: Creating and Editing Log Formats 

You should first decide what protocols and log formats you want to use, the logging policy, and the 
upload schedule. Then you can do the following: 

□ Associate a log format with the log facility 

□ Associate a log facility with a protocol and / or create policies for protocol association and to 
manage the access logs and generate entries in them (if you do both, policy takes precedence). 

□ Determine the upload parameters for the log facility. 

The Format tab allows you to create a format to use for your log facilities. Several log formats ship 
with the ProxySG, and they might be sufficient for your needs. If so, you do not need to use the 
Format tab and can skip to "Creating an Access Log Facility" on page 897. If the formats that exist do 
not meet your needs, you can use the Format tab to create a custom or ELFF format and specify the 
string and other qualifiers used. 

Several log formats already exist. For a description of each value, see Appendix B: "Access Log 
Formats" on page 1041: 

□ im (Instant Messaging): This is an ELFF format with the custom strings of: 

date time c-ip cs-username cs-auth-group cs-protocol x-im-method x-im-user-id 
x- im-user-name x-im-user-state x-im-client-info x-im-buddy-id x- im- buddy -name 
x- im-buddy- state x-im-chat-room-id x-im-chat-room-type x-im-chat-room-members 
x-im-message-text x-im-message-size x-im-message-route x-im-message-type 
x-im-f ile-path x-im-f ile-size s-action 

□ main: This is an ELFF format with custom strings of: 

date time time-taken c-ip sc-status s-action sc-bytes cs-bytes cs-method 
cs-uri-scheme cs-host cs-uri-port cs-uri-path cs-uri-query cs-username 
cs-auth-group s-hierarchy s-supplier-name rs (Content -Type) cs (User-Agent ) 
sc-f ilter-result cs-category x-virus-id s-ip s-sitename 

□ ncsa: This is a reserved format that cannot be edited. The NCSA/Common format contains the 
following strings: 

remotehost rfc931 authuser [date] "request" status bytes 

The ELFF / custom access log format strings that represent the strings above are: 

$(c-ip) - $ (cs-username) $ (localtime) $ (cs-request-line) $ (sc-status) 

$ (sc-bytes) 

□ p2p: This is an ELFF format with custom strings of: 

date time c-ip c-dns cs-username cs-auth-group cs-protocol x-p2p-client-type 
x-p2p-client-info x-p2p-client -bytes x-p2p-peer-bytes duration s-action 

□ smartreporter: This is a reserved format that cannot be edited. It contains the following string: 

localtime s-computername c-ip c-uri sc-f ilter-result cs-categories cs-user 
sc-bytes 

□ squid: This is a reserved format that cannot be edited. You can create a new SQUID log format 
using custom strings. The default SQUID format is SQUID-1.1 and SQUID-2 compatible. 

SQUID uses several definitions for its field formats: 
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SQUID-l:time elapsed remotehost code/status/peerstatus bytes method URL 
SQUID-1.1: time elapsed remotehost code/status bytes method URL rfc931 
peerstatus/peerhost type 

SQUID-2 has the same fields as SQUID-1.1, although some of the field values have changed. 

□ ssl: This is an ELFF format with custom strings of: 

date time time-taken c-ip s-action x-rs-certif icate-validate-status 
x-rs-certif icate-observed-errors cs-host s-hierarchy s-supplier-name 
x-rs- connect ion -negotiated- ssl -version x-rs- connect ion -negotiated- cipher 
x-rs- connect ion -negotiated -cipher -size x-rs-certif icate -hostname 
x-rs-certif icate -hostname -category x-cs- connect ion -negotiated- ssl -vers ion 
x-cs- connect ion -negotiated- cipher x-cs -connect ion-negotiated- cipher -size 
x-cs-certif icate- sub j ect s-ip s-sitename 

□ streaming: This is an ELFF format with custom strings of: 

c-ip date time c-dns cs-uri-scheme cs-host cs-uri-port cs-uri-path cs-uri-query 
c-starttime x-duration c-rate c-status c-playerid c-playerversion 
c-playerlanguage cs (User-Agent ) cs (Referer) c-hostexe c-hostexever c-os 
c-osversion c-cpu filelength filesize avgbandwidth protocol transport audiocodec 
videocodec channelURL sc-bytes c-bytes s-pkts-sent c-pkts-received 
c-pkts-lost-client c-pkts-lost-net c-pkts-lost-cont-net c-resendreqs 
c-pkts-recovered-ECC c-pkts-recovered-resent c-buf f ercount c-totalbuf f ertime 
c-quality s-ip s-dns s-totalclients s-cpu-util x-cache-user x-cache-info 
x- client -address 

□ surfcontrol, surfcontrolv5, and smartfilter: These are reserved formats that cannot be edited. 

□ websense: This is a reserved format that cannot be edited. 

□ bcreportermain_vl: This is a reserved format that cannot be edited. 

□ bcreporterssl_vl: This is a reserved format that cannot be edited. It only contains fields that do not 
reveal private or sensitive information, unlike the bcreportermain_vl format. 



Note: If you had previously created formats with the name smartreporter or surfcontrolv5 and 

you upgrade your ProxySG, those formats are changed to smartreporter _user or 
surfcontrolv5_user. If you already have a log format named smartreporter _user or 
surfcontrolv5_user, then the names will be smartreporter _userl or surfcontrolv5_userl. This 
naming protocol continues (_user2, _user3...) as long as necessary. The logs associated 
with these formats are automatically associated with the new format name. 
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Creating a Custom or ELFF Log Format 

If you are using one of the already-existing formats, skip to "Creating an Access Log Facility" on 
page 897. Complete the following steps to create a custom or ELFF log format. 

To Create and Edit the Log Format through the Management Console 
1. Select Configuration>Access Logging>Formats. 

The Formats tab displays the current log formats. 



Formats 

Log Formats: 



Name Type Attributes 



squid 


Squid 


Log-last-header 


ncsa 


NCSA 


Log-last-header 


main 


ELFF 


Log-last-header 


im 


ELFF 


Log-last-header 


streaming 


ELFF 


Log-last-header 


websense 


Websense 


Log-last-header 


surfcontrol 


SurfControl 


Log-last-header 


smartreporter 


ELFF 


Log-last-header 


surfcontrolv5 


SurfControl 


Log-last-header 


p2p 


ELFF 


Log-last-header 


ssl 


ELFF 


Log-last-header 





New | | Edit ] | Delete 



Figure 20-3: Formats Tab 

2. To create or edit a new custom or ELFF log format, click New; to edit an existing ELFF log format 
(such as im, main, p2p, ssl, or streaming), highlight the format to be changed and click Edit. If you 
select an unconfigurable format, you receive an error message. 

The Create/Edit Format dialog displays. 
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Figure 20-4: Create Format Dialog 

3. If you are creating a new format, provide a name meaningful to you. 

4. Use the Format Settings radio buttons to select a log format; specify the string in the field below. 

Note: ELFF strings cannot start with spaces. 

5. Click Test Format to test whether the format-string syntax is correct. 

When you click Test Format, a line displays below the field that indicates that testing is in progress 
and then gives a result, such as Format is valid. 

Note: To doublecheck the format-string syntax, see "Creating a Custom or ELFF Log Format" on 

page 894 or Appendix B: "Access Log Formats" on page 1041. 

6. From the Multiple-valued header policy drop-down list, select a header to log: Log last header, log first 
header, log all headers. 

The Multiple valued header policy allows you to determine what happens with HTTP-headers that 
have multiple headers. 

7. Click OK; click Apply. 

To Create and Edit a Custom or ELFF Log Format through the CLI 

1. To create a custom or ELFF log format name, enter the following commands from the (conf ig) 
command prompt (skip to step 2 to edit an existing ELFF format log): 

SGOS# (config) access-log 

SGOS# (config access-log) create format format_name 

2. To edit a newly created or existing log format: 
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SGOS# (config access-log) edit format format_name 

The prompt changes to: 

SGOS# (config format format_name) 

3. To customize the log format: 

SGOS# (config format format_name) type {custom | elff} format_string 

SGOS# (config format format_name) multi -valued-header-policy { log-all -headers | 

log-first-header | log-last-header} 



where 



type 


{custom | elff} 
format string 


Specifies the log format. 


multi -valued -header 
-policy 


log-all -headers | 
log- first -header 

log -last -header 


(Optional) Specifies which headers should 
be logged. The default is 
log -last -header. 



4. (Optional) View the results. 

SGOS# (config format format_name) view 
Settings : 

Format name: format_name 

Type elff "date time time-taken c-ip sc-status s-action sc-bytes cs-bytes 
cs-method cs-uri-scheme cs-host cs-uri-path cs-uri-query cs-username s-hierarchy 
s-supplier-name rs (Content -Type) cs (User-Agent ) sc-f ilter-result 
sc-f ilter-category x-virus-id s-ip s-sitename" 

Multiple -header -policy log- last -header 

5. (Optional) To delete a log format: 

SGOS# (config) access-log 

SGOS# (config access-log) delete format format_name 

Boundary Condition: Creating a Custom or ELFF Log Format 

The access log ignores any ELFF or custom format fields it does not understand. In a downgrade, the 
format still contains all the fields used in the upgraded version, but only the valid fields for the 
downgraded version display any information. 
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Section C: Creating an Access Log Facility 

You can use existing log facilities and modify them for your needs. You can also create new log 
facilities for special circumstances, such as associating the SurfControl log format with a log facility To 
create new log facilities, continue with the next section. If you need to edit an existing log facility, skip 
to "Editing an Existing Log Facility” on page 899. 



Note: Several log facilities have already been created. Before creating a new one, check the 

existing ones to see if they fit your needs. If you want to use a custom log format with the 
new log facility, you must create the log format before associating it with a log (see 
"Creating and Editing Log Formats" on page 892). 



To Create a Log Facility through the Management Console 
1. Select Configuration>Access Logging>Logs>Logs. 

Logs | General Settings ] Upload Client | Upload Schedule 

- Logs: 



Name Format 



main 


main 


im 


im 


streaming 


streaming 


p2p 


p2p 


ssl 


ssl 





New ~| [ Delete^ 



Figure 20-5: Logs Tab 

2. The log facilities already created are displayed in the Logs tab. To create a new log, click New. 
The Create Log dialog displays. 
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' Create Log 



JnjxJ 



Log Settings: 

Log Name: 
Log Formal 
Description 




OK | Cancel | 

Figure 20-6: Create Log Dialog 

3. Fill in the fields as appropriate: 

• Log Name: Enter a log facility name that is meaningful to you. 

• Log Format: Select a log format from the drop-down list. 

• Description: Enter a meaningful description of the log. It is used for display purposes only. 

4. Fill in the Log file limits panel as appropriate. (You can edit these settings later. See "Editing an 

Existing Log Facility" below.) 

• The maximum size for each remote log file (the file on the upload server) defaults to 0, 
meaning that all data is sent to the same log file. If you set a maximum size, a new log file 
opens when the file reaches that size. This setting is valid for both periodic and continuous 
uploads. 

• Specify a size that triggers an early upload — the maximum upload size varies depending on 
the size of the ProxySG disks (the maximum allowed upload threshold appears below this 
field). 

5. Click OK; click Apply. 

To Create a Log Facility through the CLI 

From the (config) command prompt, enter the following commands: 

SGOS# (config) access-log 

SGOS# (config access-log) create log log_name 

See "Editing an Existing Log Facility" below for information on configuring the newly created log. 



|l 

| squid ^ 

: I 
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Section D: Editing an Existing Log Facility 

A number log facilities exist, each associated with a log format. For a description of the format, see 
"Creating and Editing Log Formats” on page 892. 

□ im (Instant Messaging): Associated with the im format. 

□ main: Associated with the main format. 

□ p2p (Peer-to-Peer): Associated with the p2p format. 

□ ssl: Associated with the SSL format. 

□ streaming: Associated with the streaming format. 

Use the following procedures to edit log facilities you have created. 



Note: If you change the log format of a log, keep in mind that ELFF formats require an ELFF 

header in the log (the list of fields being logged are mentioned in the header) and that 
non-ELFF formats do not require this header. 

The format of data written to the log changes as soon as the format change is applied; for 
best practices, do a log upload before the format change and immediately after (to 
minimize the number of log lines in a file with mixed log formats). 

Upload the log facility before you switch the format. 



To Edit an Existing Log Facility through the Management Console 
1. Select Configuration>Access Logging>Logs>General Settings. 

Logs General Settings | Upload Client | Upload Schedule 

Log: main v 




- Log file limits: 

The maximum size of each remote file is | 0 megabytes 

Start an early upload if log reaches | 822 megabytes 

Note: The maximum allowed upload threshold is: 1027 megabytes 

Figure 20-7: General Settings Tab 
2. Fill in the fields as appropriate: 

• Log: Select an already-existing log facility from the Log drop-down list. 

• Log Format: Select the log format from the drop-down list. 
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• Description: Enter a meaningful description of the log. (If you chose an existing log format, the 
default description for that log is displayed. You can change it.) 

3. Fill in the Log file limits panel as appropriate: 

• The maximum size for each remote log file (the file on the upload server) defaults to 0, 
meaning that all data is sent to the same log file. If you set a maximum size, a new log file 
opens when the file reaches that size. This setting is valid for both periodic and continuous 
uploads. 

• Specify a size that triggers an early upload — the maximum upload size varies depending on 
the size of the ProxySG disks (the maximum allowed upload threshold appears below this 
field). 

4. Click OK; click Apply. 

To View an Existing Log Facility through the CLI 

A log facility must exist before you can edit it. You can view all the created log facilities with their 
configured settings through the CLI. The example below shows the settings for only one log facility. 
To view settings for a particular log facility only, include the optional log_name argument. 

To view the existing log formats on the system, enter the following command: 

SGOS# (config) show access-log log [ log_name ] 

Settings : 

Log name: main 
Format name : main 

Description: Use for protocols having no specific default log (such as im) 

Logs uploaded using FTP client 
Logs upload as gzip file 

Wait 60 seconds between server connection attempts 
Log encryption disabled 
FTP client: 

Filename format: SG_%f_%c_%l%m%d%H%M%S . log 
Filename uses utc time 
Use PASV : yes 

Use secure connections: no 
Primary host site: 

Host : 

Port: 21 
Path : 

Username : 

Password: ************ 

Alternate host site: 

Host : 

Port: 21 
Path : 

Username : 

Password: ************ 

HTTP client: 

Filename format: SG_%f_%c_%l%m%d%H%M%S . log 
Filename uses utc time 
Use secure connections: no 
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Primary host site: 

Host : 

Port: 80 
Path : 

Username : 

Password: ************ 

Alternate host site: 

Host : 

Port: 80 
Path : 

Username : 

Password: ************ 

Custom client: 

Primary server: :69 

Alternate server: :69 

Use secure connections : no 
Websense client: 

Primary server: : 55805 

Alternate server: : 55805 

Log uploading: 

Log is uploaded daily at 02:00 
No bandwidth class has been set for uploads 
A keep-alive log packet is sent every 300 seconds 
Start an early upload when log reaches 1736 megabytes 
Remote log file rotation by size is disabled 

To Edit an Existing Log Facility through the CLI 

Once you know which log facility you want to edit, complete the following procedure. 

1. From the (config) command prompt, enter the following commands: 

SGOS# (config) access-log 

SGOS# (config access-log) edit log log_name 
SGOS# (config log log_name) format-name format_name 
SGOS# (config log log_name) early-upload megabytes 
SGOS# (config log log_name ) remote-size megabytes 



where 



format -name 


format name 


Specifies a log format for this log facility. The format 
name can be any format that already exists on the 
ProxySG. 


early-upload 


megabytes 


Specifies the size that triggers an early upload — the 
maximum upload size varies depending on the size of 
the ProxySG disks. 


remote- size 


megabytes 


Specifies the maximum size for each remote log file 
(the file on the upload server). The default is 0, 
meaning that all data is sent to the same log file. If you 
set a maximum size, a new log file opens when the file 
reaches that size. This setting is valid for both periodic 
and continuous uploads 
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2. (Optional) View the results. 

SGOS# (config log log_name) view 



Note: The output includes all the defaults for the log facility, whether or not you configured 

them. 



3. (Optional) To delete a log facility: 

SGOS# (config) access-log 

SGOS# (config access-log) delete log log_name 



Note: Deleting the log deletes any existing log entries on the ProxySG. To avoid this, upload the 

access log entries before deleting the logs. 
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Section E: Associating a Log Facility with a Protocol 

You can associate a log facility with a protocol at any point in the process. New systems have certain 
protocols associated with certain logs by default. This allows you to begin access logging as soon as it 
is enabled (see "Enabling or Disabling Access Logging" on page 891). 



Note: If you have a policy that defines protocol and log association, that policy overrides any 

settings you make here. 



The following list shows the protocols supported and the default log facilities assigned to them, if any: 
Table 20-1 . Default Log Facility Assignments 



Protocol 


Assigned Default Log Facility 


Endpoint Mapper 


main 


FTP 


main 


HTTP 


main 


HTTPS-Reverse-Proxy 


main (Set to the same log facility that HTTP is using upon 
upgrade.) 


HTTPS-Forward-Proxy 


ssl (If the facility for HTTP, TCP, or SOCKS is set before 
upgrade.) 


ICP 


none 


Instant Messaging 


im 


MAPI 


mapi 


Peer to Peer 


p2p 


RealMedia / QuickTime 


streaming 


SOCKS 


none 


SSL 


ssl (If the facility for HTTP, TCP or SOCKS is set before 
upgrade.) 


TCP Tunnel 


main 


Telnet 


main 


Windows Media 


streaming 
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Note: To disable access logging for a particular protocol, you must either disable the default 

logging policy for that protocol (see "Disabling Access Logging for a Particular Protocol" 
on page 905) or modify the access logging policy in VPM (see "Modify Access Logging” 
on page 632). 



To Associate a Log Facility with a Protocol through the Management Console 

1. Select Configuration>Access Logging>General>Default Logging. 

2. Highlight the protocol you want to associate with a log facility and click Edit. 

The appropriate Edit Logging dialog appears. 

3. Select a log facility from the Default Log drop-down list. 

Note: To disable access logging for that protocol, select none. 

4. Click OK. 

5. Click Apply. 

To Associate a Log Facility with a Protocol through the CLI 

1. From the (config) command prompt, enter the following commands: 

SGOS# (config) access-log 

SGOS# (config access-log) default-logging {epmapper | icp | ftp | http | 

https -forward-proxy | https-reverse-proxy | im | irons | p2p | rtsp | socks | ssl | 

tcp- tunnel | telnet} log_name 



where: 



epmapper 


log name 


Sets the default log facility for endpoint mapper. 


ftp 


log name 


Sets the default log facility for FTP. 


http 


log name 


Sets the default log facility for HTTP. 


https -forward-proxy 


log name 


Sets the default log facility for HTTPS forward 
proxy. 


https -reverse -proxy 


log name 


Sets the default log facility for HTTPS reverse 
proxy 


icp 


log name 


Sets the default log facility for ICP. 


im 


log name 


Sets the default log facility for IM. 


mms 


log name 


Sets the default log facility for MMS. 


P2p 


log name 


Sets the default log facility for Peer-to-Peer. 


rtsp 


log name 


Sets the default log facility for Real 
Media/ QuickTime. 
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socks 


log name 


Sets the default log facility for SOCKS. 


ssl 


log name 


Sets the default log facility for SSL. 


tcp -tunnel 


log name 


Sets the default log facility for TCP tunneling. 


telnet 


log name 


Sets the default log facility for Telnet Proxy. 



2. (Optional) View the results. 

SGOS# (config access-log) view default-logging 
Default Logging: 

Protocol Log 



epmapper 

ftp 

http 

https- forward-proxy 

https -reverse -proxy 

icp 

im 

mms 

p2p 

rtsp 

socks 

ssl 

tcp- tunnel 
telnet 



main 

main 

main 

ssl 

main 

<none> 

im 

streaming 

p2p 

streaming 

<none> 

ssl 

main 

main 



Disabling Access Logging for a Particular Protocol 

To Disable Access Logging for a Particular Protocol through the Management Console 

1. Select Configuration>Access Logging>General>Default Logging. 

2. Highlight the protocol for which you want to disable access logging and click Edit. 

The appropriate Edit Logging dialog appears. 

3. Select none from the drop-down menu. 

4. Click OK. 

5. Click Apply. 

To Disable Access Logging for a Particular Protocol through the CLI 

From the (config) command prompt, enter the following commands: 

SGOS# (config) access-log 

SGOS# (config access-log) no default- logging {epmapper | ftp | http | 
https- forward-proxy | https -reverse -proxy | icp | im | mms | p2p | rtsp | socks 
| tcp- tunnel | telnet} 
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where access logging is disabled for the protocol command you enter. 
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Section F: Configuring Global Settings 

You can set global limits for log size and early upload times. These settings can be overridden by 
individual log facilities. 

To Set Global Log Facility Limits through the Management Console 

1. Select Configuration>Access Logging>General>Global Settings. 



Default Logging Global Settings 

- Global Log File Limits 

Limit total system access logging to 1 028 megabytes 

If maximum log size is reached: 

® stop logging 
Q delete oldest log entries 

Start an early upload if total logging reaches 822 megabytes 

Note: The global early upload setting can be overridden on a per-log basis 



- Global Upload 

| Upload All | log files from logs using periodic upload. 

| Cancel All | log file uploads currently in progress. 

Figure 20-8: Global Settings Tab 

2. Fill in the Global Log File Limits panel as appropriate: 

• Configure the maximum size occupied by all of the log files (in megabytes). 

• Determine the behavior of the log when the maximum size is reached. You can have the log 
stop logging (and do an immediate upload) or have it delete the oldest log entries. 

• Specify the size of the log that triggers an early upload. 

3. The Global Upload options affect all log facilities currently available. They do not affect scheduled 
upload times. You can upload logs now, using the periodic upload method, or you can cancel all 
the uploads that are currently in progress. 



To Set Global Log Facility Limits through the CLI 



From the (config) command prompt, enter the following commands: 



SGOS# (config) 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 



access-log 

access-log) 

access-log) 

access-log) 

access-log) 



overflow-policy {delete | stop} 
early-upload megabytes 
upload {all | log log_name } 
cancel-upload {all | log log_name } 



where 



overflow -policy 



delete | stop 



When the log reaches its maximum size, you can 
delete the oldest log entries, or you can stop logging 
(and do an immediate upload). 
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early-upload 


megabytes 


Specifies the size of the log before an upload can take 
place. 


upload 


{all | log 
log_name} 


An immediate upload for all logs or a specified log. 


cancel -upload 


{all | log 
log_name } 


Cancels the current upload for all logs or a specified 
log. 
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Section G: Configuring the Upload Client 

Blue Coat supports four types of upload client: 

□ FTP client, the default 

□ HTTP client 

□ Custom client 

□ Websense client 

Blue Coat also supports secure FTP, HTTP, and Custom client. 

The Custom client can be used for special circumstances, such as working with SurfControl Reporter. 
Custom client is based on plain sockets. 

Note: You must have a socket server to use the Custom client. 



The general options you enter in the Upload Client tab affect all clients. Specific options that affect 
individual clients are discussed in the FTP client, HTTP client. Custom client, or Websense client 
panes or the access-log ftp-client, https-client, custom-client, or websense-client CLI 
commands. 

Only one client can be used at any one time. All four can be configured, but only the selected client is 
used. 

The ProxySG provides access logging with two types of uploads to a remote server: 

□ continuous uploading, where the ProxySG continuously streams new access log entries from the 
ProxySG memory to a remote server 

□ scheduled (periodic) uploading, where the ProxySG transmits log entries on a scheduled basis. 
See "Configuring the Upload Schedule" on page 930 for more information. 

The ProxySG allows you to upload either compressed access logs or plain-text access logs. The 
ProxySG uses the gzip format to compress access logs. Gzip-compressed files allow more log entries 
to be stored in the ProxySG. Advantages of using file compression include: 

□ Reduces the time and resources used to produce a log file because fewer disk writes are required 
for each megabyte of log-entry text. 

□ Uses less bandwidth when the ProxySG sends access logs to an upload server. 

□ Requires less disk space. 

Compressed log files have the extension . log . gz. Text log files have the extension . log. 



Note: You cannot upload gzip access-log files for the Websense client. 



For greater security, you can configure the ProxySG to 
□ encrypt the access log 
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□ sign the access log 

Encrypting the Access Log 

To encrypt access log files, you must first place an external certificate on the ProxySG (see "Importing 
an External Certificate" on page 910). The ProxySG derives a session key from the public key in the 
external certificate and uses it to encrypt the log. When an access log is encrypted, two access log files 
are produced: an ENC file (extension . enc), which is the encrypted access log file, and a DER file 
(extension . der), which contains the ProxySG session key and other information. You need four 
things to decrypt an encrypted access log: 

□ The ENC file 

□ The DER file 

□ The external (public key) certificate 

□ The corresponding private key 

For information about decrypting a log, see "Decrypting an Encrypted Access Log" on page 917. 



Note: The encryption feature is not available for custom or Websense clients. 



Importing an External Certificate 

You can import an X.509 certificate into ProxySG to use for encrypting data (see "Configuring the 
Upload Client" on page 909). 

To Import an External Certificate through the Management Console 

1. Copy the certificate onto the clipboard. 

2. Select Configuration>SSL>External Certificates. 
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External Certificates 

r External Certificates: 




Figure 20-9: External Certificates Tab 
3. Click Import. 

The Import External Certificate dialog displays. 



Import: External Certificate 



Import External Certificate: 



JnJxj 



External Cert Name: jextcert 
External Certificate: 



--BEGIN CERTIFICATE-— 

MIICiT CCAfKgAwl B Agl E N 4dnrDAN B gkqhkiG 9wOB AQ U FAD B 1 M Q swCQ YD VQ Q G E wd i "J 
ZTERMA8GA1UEChMIQmVsZ2Fib20xDDAKBgNVBAsTA01UTTEkMCIGA1UEAxMbQ 

mVs 

Z2Fib20gR S 1 U cnVzdCB Q cmltVXJ 51 E N B M R 8wH Q YKCZI miZPyLG Q BAxQ PaW5mbOB I 
LXRyct<NOLrrdlMB4XDTk4MTEwNDEzMDQzOVcXDTEwMDEyMTEzMDQzOVowdTE 



OK | Cancel | 

Figure 20-10: Import External Certificate Dialog 

4. Enter the name of the external certificate into the External Cert Name field and paste the certificate 

into the External Certificate field. Be sure to include the begin certificate and 

end certificate statements. 

5. Click OK. 

6. Click Apply. 
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To Import an External Certificate through the CLI Using Inline Commands 

1. Copy the certificate or certificate chain to the clipboard. Be sure to include the begin 

CERTIFICATE and END CERTIFICATE statements. 

2. From the (conf ig) prompt, enter the following commands to paste the certificate and enter the 
eof marker: 

SGOS# (conf ig) ssl 

SGOS# (config ssl) inline external-certificate keyring_id eof 
Paste certificate here 
eof 

Viewing an External Certificate 

To View an External Certificate through the CLI 

SGOS# (conf ig) ssl 

SGOS# (config ssl) view external-certificate certificate_name 
BEGIN CERTIFICATE 

MIICiTCCAf KgAwIBAgIEN4dnrDANBgkqhkiG9wOBAQUFADBlMQswCQYDVQQGEwJi 
ZTERMA8GAlUEChMIQmVsZ2Fjb2 OxDDAKBgNVBAsTAOlUTTEkMCIGAlUEAxMbQmVs 
Z2Fjb20gRSlUcnVzdCBQcmltYXJ5IENBMR8wHQYKCZImiZPyLGQBAxQPaW5mb0Bl 
LXRydXNOLmJlMB4XDTk4MTEwNDEzMDQzOVoXDTEwMDEyMTEzMDQzOVowdTELMAkG 
AlUEBhMCYmUxETAPBgNVBAoTCEJlbGdhY29tMQwwCgYDVQQLEwNNVE0xJDAiBgNV 
BAMTG 0 J1 bGdhY2 9tIEUtVHJlc3 QgUH JpbWFye SBDQTEfMBO GCgmS JomT 8 ixkAQMU 
D21uZm9AZS10cnVzdC5iZTCBnzANBgkqhkiG9wOBAQEFAAOB j QAwgYkCgYEAqtm5 
s9VPak3FQdB7BGFqi3GBB9pk41huJlXCrc4XsPz6ko0I8Bxy/7LDMf 7gaoeXTMxD 
V6coeTqlgl2kHWrxasU+FCIdWQZv8KYxd9ywSTjmywwP/qpyNI j aKDohWu5 0Kxuk 
2 lsTFrVzX80u j NLAP j 2wy/Dsi4 YLwsFEGFp j qNUCAwEAAaMmMCQwDwYDVROTBAgw 
BgEB/wIBATARBglghkgBhvhCAQEEBAMCAAcwDQYJKoZIhvcNAQEFBQADgYEAerKx 
pbF9M+nC4Rv0050MfwH9Gxlamq6rBlEv7Ymr3VBCux//SrWknLFhKQpM6oNZSY2v 
hmnXgaxHqqRxblnvynxqblSK2qiSyfVms31f HsBniFjRjWTpcJf ImIDcBl j I+hr 
SBO j ECfY9t9HorrsgFBKbMRwpnrkdCJ / 9oRiMn7 = 

END CERTIFICATE 

To View the External Certificate Summary through the CLI 

SGOS# (conf ig) ssl 

SGOS# (config ssl) view summary external-certificate 

Certificate ID: testl 
Is certificate valid? yes 
CA: Blue Coat SG3000 

Expiration Date: Sep 24 19:33:30 2014 GMT 

Fingerprint : 72 : D5 : 7F : 9F : BO : CA: D2 : 54 : 24 : 47 : A4 : 7A : 37 : 48 : 63 : D9 

Deleting an External Certificate 
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To Delete an External Certificate through the Management Console 

1. Select Configuration>SSL>External Certificates. 

2. Highlight the name of the external certificate to be deleted. 



Chapter 20: Access Logging 



Section G: Configuring the Upload Client 

3. Click Delete. 

The Confirm delete dialog appears. 

4. Click OK in the Confirm delete dialog that appears; click Apply. 

To Delete an External Certificate through the CLI 

From the (config) prompt, enter the following commands: 

SGOS# (conf ig) ssl 

SGOS# (config ssl) delete external-certificate certificate_name 

Digitally Signing Access Logs 

You can digitally sign access logs to certify that a particular ProxySG wrote and uploaded this log file. 
Signing is supported for both content types — text and gzip — and for both upload types — continuous 
and periodic. Each log file has a signature file associated with it that contains the certificate and the 
digital signature for verifying the log file. The signature file has the same name as the access log file 
but with a .sig extension; that is, filename . log . sig, if the access log is a text file, or 
filename . log . gzip . sig, if the access log is a gzip file. 



Note: Signing is disabled by default. 



You can digitally sign your access log files with or without encryption. If the log is both signed and 
encrypted, the signing operation is done first, meaning that the signature is calculated on the 
unencrypted version of the file. You must decrypt the log file before verifying the file. Attempting to 
verify an encrypted file fails. 

When you create a signing keyring (which must be done before you enable digital signing), keep in 
mind the following: 

□ The keyring must include a private key and a corresponding x.509 certificate. 

□ The certificate purpose must be set for smime signing. If the certificate purpose is set to anything 
else, you cannot use the certificate for signing. 

□ Add the %c parameter in the filenames format string to identify the keyring used for signing. If 
encryption is enabled along with signing, the %c parameter expands to keyringName_Certname. 



Note: The signing feature is not available for custom or Websense clients. 



For information about verifying a log, see "Verifying a Digital Signature" on page 917. 
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To Configure the Upload Client through the Management Console 

1. Select Configuration>Access Logging>Logs>Upload Client. 



Logs 



General Settings 



Upload Client J Upload Schedule 



Log: 



Upload Client: 
Client type: 



NONE 



Settings 



Test Upload 



T ransmission Parameters: 

Encryption Certificate: 
Keyring Signing : 

Save the log file as: 
Send partial buffer after: 
Bandwidth Class: 



No Encryption 



No Signing 



® gzip file O 

seconds 



30 



<none> v 



Figure 20-11: Upload Client Tab 



2. From the Log drop-down list, select the log facility to configure. The facility must exist before it 
displays in this list. 

3. From the Client type drop-down list, select the upload client to use. Only one client can be 
configured for each log facility. 

4. Click Settings to customize the upload client. 

For information on customizing the clients, skip to "Editing the FTP Client" on page 918, "Editing 
the FITTP Client" on page 922, "Editing the Custom Client" on page 925, "Editing the Custom 
SurfControl Client" on page 927, or "Editing the Websense Client" on page 928. 

For information about testing the upload client, see "Testing Access Log Uploading" on page 933. 

5. (Optional) To use an external certificate to encrypt the uploaded log facility, select an external 
certificate from the Encryption Certificate drop-down list. You must first import the external 
certificate to the ProxySG (see "Importing an External Certificate" on page 910). 

The encryption option is not available for Websense or Custom clients. 

6. (Optional) To enable the digital signature of the uploaded access log, select a keyring from the 
Keyring Signing drop-down list. The signing keyring, with a certificate set to smime, must already 
exist. A certificate set to any other purpose cannot be used for digital signatures. 

The digital signing option is not available for Websense or Custom clients. 

7. Select one of the Save the log file as radio buttons to determine whether the access log that is 
uploaded is compressed (gzip file, the default) or not (text file). 



Note: If you are configuring a SurfControl Custom client, select the text file radio button. 



914 



Chapter 20: Access Logging 



Section G: Configuring the Upload Client 



8. If you chose text file, you can change the Send partial buffer after n seconds field to the time you need 
(30 seconds is the default). 

This field configures the maximum time between text log packets, meaning that it forces a text 
upload after the specified length of time even if the internal log buffer is not full. If the buffer fills 
up before the time specified in this setting, the text uploads right away, and is not affected by this 
maximum setting. 



Note: If you chose gzip file, the Send partial buffer after n seconds field is not configurable. Also, 

this setting is only valid for continuous uploading (see "Configuring the Upload 
Schedule" on page 930 for information about continuous uploading). 



9. (Optional) To manage the bandwidth for this log facility, select a bandwidth class from the 
Bandwidth Class drop-down list. 

The default setting is none, which means that bandwidth management is disabled for this log 
facility by default. 



Note: Before you can manage the bandwidth for this log facility, you must first create a 

bandwidth-management class. It is the log facility that is bandwidth-managed — the 
upload client type does not affect this setting. See Chapter 10: "Bandwidth Management" 
on page 489 for information about enabling bandwidth management and creating and 
configuring the bandwidth class. 

Less bandwidth slows down the upload, while more could flood the network. 



10. Click Apply. 
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To Configure the Upload Client through the CLI 



From the (conf ig) command prompt, enter the following commands to make general settings for the 
upload client. 

SGOS# (config) access-log 

SGOS#(config access-log) edit log log_name 



SGOS# (config log log^name) 
SGOS# (config log log_name) 
SGOS# (config log log_name) 
SGOS# (config log log_name) 
SGOS# (config log log_name) 
SGOS# (config log log_name) 
websense- client 



client-type {custom | ftp | http | websense} 
upload-type (gzip | text} 
bandwidth-class class_name 
encryption certificate certificate_name 
signing keyring_id 

ftp-client | http-client | custom-client 



where 



client-type 


custom | ftp | 
http | websense 


Specifies which upload client to use. Only one 
client can be configured for each log. 


upload- type 


gzip | text 


Specifies upload as a gzip or a text file. Websense 
client always uploads a text file. 


bandwidth- cl ass 


class name 


Specifies a bandwidth-management class for 
managing the bandwidth of this log. 

IMPORTANT: Before you can manage the 
bandwidth for this log, you must create a 
bandwidth-management class. See Chapter 10: 
"Bandwidth Management" on page 489 for 
information about creating and configuring 
bandwidth classes. 


no 


bandwidth- class 


Disables bandwidth management for this log. 


encryption 


certificate 
certificate name 


Specifies the access log encryption certificate. 
Cannot be used for Websense or Custom clients. 


no 


encryption 


Disables access log encryption. 


signing 


keyring id 


Specifies the keyring to be used for digital 
signatures. 


no 


signing 


(Default) Disables access log digital signature. 


ftp-client 




Edits the FTP client configuration. Skip to "Editing 
the FTP Client" on page 918 for more information. 


http-client 




Edits the HTTP client configuration. Skip to 
"Editing the HTTP Client" on page 922 for more 
information. 


custom-client 




Edits the Custom client configuration. Skip to 
"Editing the Custom Client" on page 925 for more 
information. 
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websense- client 



Edits the Websense client configuration. Skip to 
"Editing the Websense Client" on page 928 for more 
information. 



Disabling Log Uploads 

To disable log uploads, set the upload client-type to none. 

To Disable an Upload through the Management Console 

1. Select Configuration>Access Logging>Logs>Upload Client. 

2. Select the log facility for which you want to disable an upload from the Log drop-down menu. 

3. Select NONE from the Client type drop-down menu. 

4. Click Apply. 

To Disable an Upload through the CLI 

From the (config) command prompt, enter the following commands: 

SGOS# (config) access-log 

SGOS# (config access-log) edit log log_name 
SGOS# (config log log_name) client-type none 

where log_name is the name of the log for which you want to disable an upload. 

Decrypting an Encrypted Access Log 

To decrypt an encrypted access log, you must concatenate the DER and ENC files (with the DER file in 
front of the ENC file) and use a program such as OpenSSL for decryption. For example, use the 
following UNIX command and a tool such as OpenSSL to concatenate the DER and ENC files and 
decrypt the resulting file: 

cat path/ filename_of_DER_file path/ filename_of_ENC_file | openssl smime -decrypt 
-inform DER -binary -inkey path/ filename_of_private_key -recip 

path/filename_of_external_certificate -out path/filename_for_decrypted_log_file 

You can also download a script based on the OpenSSL tool for decryption. Go to 
https:/ / download.bluecoat.com/ release/SG4/ files/ accesslog_decrypt.zip. 

Verifying a Digital Signature 

If the file whose digital signature you want to verify is also encrypted, you must decrypt the file prior 
to verifying the signature. (See "Decrypting an Encrypted Access Log” above for more information.) 

You can use a program such as OpenSSL to verify the signature. For example, use the following 
command in OpenSSL: 

openssl smime -CAfile cacrt -verify -in filename . sig -content filename.log 
-inform DER -out logFile 
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where 



cacrt 


The CA certificate used to issue the certificate in the signature file. 


filename . sig 


The file containing the digital signature of the log file. 


filename . log 


The log file generated after decryption. If the access log is a gzip file, it contains 
a . gz extension. 


1 ogFi 1 e 


The filename that is generated after signature verification. 



Editing Upload Clients 

Four upload clients are supported by Blue Coat: FTP, HTTP, Custom, and Websense. Each of these 
clients are described below. You can also create a SurfControl or SmartFilter upload client. 

Multiple upload clients can be configured per log facility, but only one can be enabled and used per 
upload. 

Editing the FTP Client 

To Edit the FTP Client through the Management Console 

1. Select Configuration>Access Logging>Logs>Upload Client. 

See "Configuring the Upload Client" on page 909 for configuration information. 

2. Select FTP Client from the Client type drop-down list. Click the Settings button. 

The FTP Client Settings dialog displays. 



. •« FTP Client settings: Log im 




OK | Cancel | 

Figure 20-12: Edit FTP Client Dialog 
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3. Select the primary or alternate FTP server to configure from the Settings for drop-down list. 

4. Fill in the fields as appropriate: 

• Host: The name of the upload client host. If the Use secure connections (SSL) checkbox is 
selected, the hostname must match the hostname in the certificate presented by the server. 

• Port: The default is 21; it can be changed. 

• Path: The directory path where the access log is uploaded on the server. 

• Username: This is the username that is known on the host you are configuring. 

• Change Password: Change the password on the FTP; the Change Password dialog displays; 
enter and confirm the new password; click OK. 

• Filename: The Filename field is comprised of text and/or specifiers. The default filename 
includes specifiers and text that indicate the log name (%f), name of the external certificate 
used for encryption, if any (%c), the fourth parameter of the ProxySG IP address (%l), the date 
and time (Month: %m. Day: %d. Flour: %H, Minute: %M, Second: %s), and the . log or . gzip . log 
file extension. 



Note: Be cautious if you change the Filename field. If an ongoing series of access logs files 

are produced and you do not have time-specifiers in this field, each access log file 
produced overwrites the old file. Also, if you use more than one external certificate to 
encrypt logs, include the %c specifier in the Filename field to keep track of which 
external certificate was used to encrypt the uploaded log file. 

If you are creating a SurfControl client, change the . log file extension to . tmp. 



• Secure Connections: If you use FTPS, select the Use secure connections (SSL) checkbox. The 
remote FTP server must support FTPS. 

• Local Time: If you want the upload to reflect the local time it was uploaded instead of 
Universal Time Coordinates (UTC), select Local Time. 

• Use PASV: With Use PASV selected (the default), the ProxySG connects to the FTP server. With 
Use PASV de-selected, the FTP server uses the PORT command to connect to the ProxySG. 

5. Click OK; click Apply. 



To Edit the FTP Client through the CLI 



1. At the (config) command prompt, configure the FTP client's primary or secondary server 
information: 



SGOS# (config) 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 



access-log 

access-log) edit log log_name 



log log_name ) 
log log_name ) 
log log_name ) 
log log_name ) 
log log_name ) 
log log_name ) 



ftp-client primary host hostname [port] 
ftp-client no primary host 
ftp-client primary path path 
ftp-client no primary path 
ftp-client primary username username 
ftp-client no primary username 
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SGOS# (config log log_name ) 
SG0S#(config log log_name) 
-or- 

SG0S# (config log log_name) 
en cryp t e d_pa s s word 
SGOS# (config log log_name) 



ftp-client primary password password 
ftp-client no primary password 

ftp-client primary encrypted-password 

ftp-client no primary encrypted-password 



where 



primary host 


hostname 

[port] 


Specifies the primary FTP server to which logs should 
be uploaded. By default, the ProxySG uses port 21. 


no primary 


{host | path [ 
username | 
password | 
encrypted- 
password} 


Deletes the primary server information. 


primary path 


path 


The path is the directory on the primary FTP server to 
which logs should be uploaded. 


primary 

username 


user name 


Specifies the username on the primary FTP server to 
which logs should be uploaded. The user name must 
have write privileges in the access log file upload 
directory. 


primary 

password 

-or- 

primary 

encrypted- 

password 


password \ 

encrypted 

password 


Specifies the password for the username in the 
previous command. The primary use of the 
encrypted-password command is to allow the 
ProxySG to load a password that it encrypted. 



2 . 



(Optional) Repeat these steps for the secondary server, replacing primary with alternate. 



SGOS# (config log log_name) 
SGOS# (config log log_name ) 
SGOS# (config log log_name ) 
SGOS# (config log log_name ) 
SGOS# (config log log_name) 
SGOS# (config log log_name) 
SGOS# (config log log_name) 
SGOS# (config log log_name ) 
-or- 

SG0S# (config log log_name) 
en cryp t e d_pa s s word 
SGOS# (config log log_name) 



ftp-client 

ftp-client 

ftp-client 

ftp-client 

ftp-client 

ftp-client 

ftp-client 

ftp-client 



alternate host hostname [port] 

no alternate host 
alternate path path 
no alternate path 
alternate username username 
no alternate username 
alternate password password 
no alternate password 



ftp-client alternate encrypted-password 



ftp-client no alternate encrypted-password 



3. Enter the following commands to complete configuration of the FTP client. 
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SGOS# (config 


log 


log_ 


name ) 


ftp-client 


filename format 




-or- 
















SGOS# (config 


log 


log_ 


name) 


ftp-client 


no filename 






SGOS# (config 


log 


log_ 


name) 


ftp-client 


pasv (yes | 


no } 




SGOS# (config 


log 


log_ 


name) 


ftp-client 


secure {yes 


1 no} 




SGOS# (config 


log 


log name) 


ftp-client 


time- format 


{ local 


utc } 


where 

















filename 


format 


The filename field is comprised of text and/or specifiers. The 
default filename includes specifiers and text that indicate the log 
name (%f ), name of the external certificate used for encryption, if 
any (%c), the fourth parameter of the ProxySG IP address (%1), the 
date and time (Month: %m. Day: %d. Hour: %H, Minute: %M, Second: 
%S), and the . log or . gzip . log file extension. 

Be cautious if you change the Filename field. If an ongoing series of 
access log files are produced and you do not have a time-specifier 
in this field, each access log file produced overwrites the old file. 
Also, if you use more than one external certificate to encrypt logs, 
include the %c specifier in the Filename field to keep track of which 
external certificate can decrypt the uploaded file. 

If you are creating a SurfControl client, you must change the . log 
file extension to . tmp. 


no filename 




Deletes the FTP client configuration parameters. 


pasv 


yes | no 


Specifies whether the ProxySG connects to the FTP server or if the 
FTP server connects to the ProxySG. The default is yes, using the 
PORT command only on failure. 


secure 


yes | no 


Specifies whether FTPS is used. The default is no. If yes, the 
hostname in Step 2 must match the hostname in the certificate 
presented by the server. 


time -format 


local | utc 


Specifies whether Universal Time Coordinates (UTC) or the local 
time is used. UTC is the default. UTC was formerly known as 
Greenwich Mean Time (GMT). 



4. (Optional) View the results. 

SGOS# (config log log_name) view 

Tip: Doing a Manual Upload for FTP Upload Client through the CLI 

Sometimes, an FTP connection is established with the FTP server and is left open. If you try to use the 
upload-now command while the connection is still open, the command fails with the error message: 

User upload request failed. There is an open- connection. Try closing the 
connection . 

To Close the Connection 

SGOS# (config access-log) edit log log_name 
SGOS# (config log log_name ) commands close-connection 
ok 
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Editing the HTTP Client 

Access log uploads done through an HTTP/HTTPS client use the HTTP PUT method. The destination 
HTTP server (where the access logs are being uploaded) must support this method. Microsoft's IIS 
allows the server to be directly configured for write (PUT/DELETE) access. Other servers, such as 
Apache, require installing a new module for the PUT method for access log client uploads. 

You can create either an HTTP or an HTTPS upload client through the HTTP Client dialog. (Create an 
HTTPS client by selecting Use secure connections (SSL).) 



Note: To create an HTTPS client, you must also import the appropriate CA Certificate. For 

information, see "Importing a CA Certificate” on page 303. 



To Edit the HTTP Client through the Management Console 

1. Select Configuration>Access Logging>Logs>Upload Client. 

See "Configuring the Upload Client" on page 909 for configuration information. 

2. Select HTTP Client from the Client type drop-down list. Click Settings. 

The HTTP Client Settings dialog displays. 



HTTP Client settings: Log main 



HTTP server connection: 




Filename: | S G_%f_%c_%l%m%d%H %M %S . log 

V Use Local Time 
V~ Use secure connections (SSL) 



OK | Cancel | 

Figure 20-13: Edit HTTP Client Dialog 

3. From the Settings for drop-down list, select the primary or alternate HTTP server to configure. 

4. Fill in the fields as appropriate: 

Host: The name of the upload host. If Use secure connections (SSL) is selected, the hostname 
must match the hostname in the certificate presented by the server. 

• Port: The default is 80, but you can change it. 
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Note: For HTTPS, change the port to 443. 



• Path: The directory path where the access log facility is uploaded on the server. 

• Username: This is the username that is known on the host you are configuring. 

• Change Password: Change the password on the HTTP host; the Change Password dialog 
displays; enter and confirm the new password and click OK. 

• Filename: The Filename field is comprised of text and/or specifiers. The default filename 
includes specifiers and text that indicate the log name (%f), name of the external certificate 
used for encryption, if any (%c), the fourth parameter of the ProxySG IP address (%l), the date 
and time (Month: %m. Day: %d. Hour: %H, Minute: %M, Second: %s), and the . log or . gzip . log 
file extension. 



Note: Be cautious if you change the Filename field. If an ongoing series of access log files are 

produced and you do not have time-specifiers in this field, each access log file 
produced overwrites the old file. Also, if you use more than one external certificate to 
encrypt logs, include the %c specifier in the Filename field to keep track of which 
external certificate can decrypt the uploaded log file. 

If you are creating a SurfControl client, change the . log file extension to . tmp. 



• Local Time: If you want the upload to reflect the local time it was uploaded instead of 
Universal Time Coordinate (UTC), select Local Time. 

• Use secure connections (SSL): Select this to create an HTTPS client. To create an HTTPS client, 
you must also create a keypair, import or create a certificate, and, if necessary, associate the 
keypair and certificate (called a keyring), with the SSL-client. 

5. Click OK; click Apply. 



To Edit the HTTP Client through the CLI 

1. At the (config) command prompt, configure the HTTP client's primary or secondary server 
information: 



SGOS# 

SGOS# 

SGOS# 

SGOS# 

SGOS# 

SGOS# 

SGOS# 

SGOS# 

SGOS# 



(config) access-log 

(config access-log) edit log log_name 

(config log log_name) http-client primary host hostname [port] 

(config log log_name ) http-client no primary host 

(config log log_name ) http-client primary path path 

(config log log_name ) http-client no primary path 

(config log log_name ) http-client primary username username 

(config log log_name) http-client no primary username 

(config log log_name) http-client primary password password 
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SGOS# (config log log_name ) http-client no primary password 

-or- 

SGOS# (config log log_name) http-client primary encrypted-password 

encryp t e d_pa s s word 

SGOS# (config log log_name) http-client no primary encrypted-password 



where 



primary host 


hostname 

[port] 


Specifies the primary HTTP server to which logs 
should be uploaded. By default, the ProxySG uses 
port 80. 

For HTTPS, change the port to 443. 


no primary 


{host | path | 
username | 
password | 
encrypted -pass 
word} 


Deletes the primary HTTP server information. 


primary path 


path 


The path is the directory on the primary HTTP 
server to which logs should be uploaded. 


primary username 


user name 


Specifies the username on the primary HTTP server 
to which logs should be uploaded. The user name 
must have write privileges in the access log file 
upload directory. 


primary password 

-or- 

primary 

encrypted-password 


password \ 
encrypted 
password 


Specifies the password (or encrypted password) for 
the username in the previous command. The 
primary use of the encrypted-password 
command is to allow the ProxySG to load a 
password that it encrypted. 



these steps for the secondary server, replacing primary with alternate 
config access-log) edit log log_name 

config log log_name ) http-client alternate host hostname [port] 

http-client no alternate host 
http-client alternate path path 
http-client no alternate path 
http-client alternate username username 
http-client no alternate username 
http-client alternate password password 
http-client no alternate password 



http-client alternate encrypted-password 



2. Repeat 

SGOS# ( 

SGOS# ( 

SGOS# ( 

SGOS# ( 

SGOS# ( 

SGOS# ( 

SGOS# ( 

SGOS# ( 

SGOS# ( 

-or- 

SG0S# (config log log_name ) 
en cryp t e d_pa s sword 
SGOS# (config log log_name ) 



config log log_name ) 
config log log_name ) 
config log log_name ) 
config log log_name ) 
config log log_name ) 
config log log_name ) 
config log log_name ) 



http-client no alternate encrypted-password 



3. (Optional) To stop the log from being uploaded to a primary or secondary server in the future, 
clear the hostname by entering an empty string (that is, double-quotes) in the following 
command: 



924 



Chapter 20: Access Logging 



Section G: Configuring the Upload Client 



SGOS# (config log log_name) 
-or- 



SGOS# (config log 



log_name ) 



http-client primary "" 
http-client alternate "" 



4. 



Enter the following 

SGOS# (config log 
SGOS# (config log 
SGOS# (config log 
SGOS# (config log 



commands to complete configuration of the HTTP 

log_name ) http-client secure {no | yes} 
log_name ) http- client filename log_name 
log_name ) http- client no filename 
log_name ) http-client time-format {utc | 



client. 



local } 



where 



secure 


no | yes 


Specifies if you want to use SSL connections. The default is 
no. If ye s, the hostname in Step 2 must match the hostname 
in the certificate presented by the server. 


filename 


log name 


The Filename field is comprised of text and/or specifiers. 
The default filename includes specifiers and text that indicate 
the log name (%f ), name of the external certificate used for 
encryption, if any (%c), the fourth parameter of the ProxySG 
IP address (%1), the date and time (Month: %m. Day: %d. 
Hour: %H, Minute: %M, Second: %S), and the . log or 
. gzip . log file extension. 

Be cautious if you change the Filename field. If an ongoing 
series of access log files are produced and you do not have a 
time-specifier in this field, each access log file produced 
overwrites the old file. Also, if you use more than one 
external certificate to encrypt logs, include the %c specifier in 
the Filename field to keep track of which external certificate 
can decrypt the uploaded log file. 

If you are creating a SurfControl client, you must change the 
. log file extension to . tmp. 


no filename 




Deletes the HTTP client configuration parameters. 


time -format 


utc | local 


Specifies whether Universal Time Coordinates (UTC) or the 
local time is used. UTC is the default. 



5. (Optional) View the results. 

SGOS# (config log log_name) view 

Editing the Custom Client 

To Edit the Custom Client through the Management Console 

1. Select Configuration>Access Logging>Logs>Upload Client. 

See "Configuring the Upload Client" on page 909 for configuration information. 

2. Select Custom Client from the Client type drop-down list. Click the Settings button. 
The Custom Client Settings dialog displays. 



925 



Blue Coat ProxySG Configuration and Management Guide 



Section G: Configuring the Upload Client 



Custom Client settings: Log streaming 



-in] x| 



Custom server connection: 



Settings for: | Primary Custom Server 






Host: | 

I - Use secure connections (SSL) 



Port: 1 69 



OK 1 Cancel | 

Figure 20-14: Edit Custom Client Dialog 

3. From the Settings for drop-down list, select the primary or alternate custom server you want to 
configure. 

4. Fill in the fields as appropriate: 

• Host: Enter the hostname of the upload destination. If Use secure connections (SSL) is selected, 
the hostname must match the hostname in the certificate presented by the server. 

• Port: The default is 69; it can be changed. 

• Use secure connections (SSL): Select this if you are using secure connections. 

5. Click OK; click Apply. 



To Edit the Custom Client through the CLI 



1 . 



At the (conf ig) command prompt, configure the Custom client's primary or secondary server 
information: 



SGOS# (conf ig) 
SGOS# (config 
SGOS# (config 
SGOS# (config 
-or- 



access-log 

access-log) edit log log_name 

log log_name) custom-client primary hostname 

log log_name ) custom-client no primary 



[port] 



SGOS# (config 
SGOS# (config 



log log_name ) 
log log_name ) 



custom-client alternate hostname 
custom-client no alternate 



[port] 



where hostname specifies the primary or alternate server to which logs should be uploaded. 
By default the ProxySG uses port 69. 

2. Enter the following command to complete configuration of the Custom client: 

SGOS# (config log log_name) custom-client secure {no | yes} 

which specifies whether SSL connections are used. The default is no. If yes, the hostname in Step 1 
must match the hostname in the certificate presented by the server. 

3. (Optional) To stop the log from being uploaded to a primary or secondary server in the future, 
clear the hostname by entering an empty string (that is, double-quotes) in the following 
command: 



926 



Chapter 20: Access Logging 



Section G: Configuring the Upload Client 



SGOS# (config log log_name ) custom-client primary "" 

-or- 

SGOS# (config log log_name) custom-client alternate "" 

4. (Optional) View the results. 

SGOS# (config log log_name ) view 

Editing the Custom SurfControl Client 

You can use the Custom Client to create an upload client that uploads information to SurfControl 
Reporter. Before you begin, verify that: 

□ You have created a log (see "Creating an Access Log Facility” on page 897). 

□ You have associated the SurfControl log format with the log you created (see "Editing an Existing 
Log Facility" on page 899). 

To Edit the SurfControl Client through the Management Console 

1. Select Configuration>Access Logging>Logs>Upload Client. 

See "Configuring the Upload Client" on page 909 for configuration information. 

2. From the Log drop-down list, select the SurfControl log that you associated with the SurfControl 
log format. 

3. Verify the Save the log file as radio button is set to text file, not gzip file. 

4. Select Custom Client from the Client type drop-down list. 

Note: For specific information on managing upload clients, see "Editing the Custom Client" on 

page 925. 

5. Click the Settings button for that client. 

6. Customize the upload client for SurfControl Reporter. 

• Enter the hostname, path, and username, if necessary, for the SurfControl Reporter server. 

• Make sure the filename extension is .tmpandnot .gzip or . log. SurfControl only recognizes 
files with a . tmp extension. 

• If your SurfControl server supports SSL, select the Use secure connections (SSL) checkbox. 

7. Click OK; click Apply. 

To Edit the Custom SurfControl Client through the CLI 

1. At the (config) command prompt, configure the customized settings for the SurfControl upload 
client: 
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SGOS# (config) access-log 

SGOS# (config access-log) edit log log_name 

SGOS# (config access-log log_name) upload-type text 

SGOS# (config access-log log_name) periodic-upload upload- interval {daily 0-23 \ 
hourly hours [minutes] } 

SGOS# (config access-log log_name) periodic-upload enable 
SGOS# (config access-log log_name) custom-client 

For specific information on managing upload clients, see "Editing the Custom Client” on page 925. 

2. (Optional) View the results. 

SGOS# (config log log_name) view 

Editing the Websense Client 

Before you begin, make sure you have created a Websense log using the Websense log format and 
configured the log to your environment. See "Creating an Access Log Facility" on page 897. 



Note: You cannot upload gzip access log files with the Websense client. 



To Edit the Websense Client through the Management Console 

1. Select Configuration>Access Logging>Logs>Upload Client. 

See "Configuring the Upload Client" on page 909 for configuration information. 

2. Select the Websense Client from the Client type drop-down list. Click the Settings button. 
The Websense Client Settings dialog displays. 



Websense Client settings: Log main 




OK | Cancel | 

Figure 20-15: Edit Websense Client Dialog 

3. From the Settings for drop-down list, select the primary or alternate server you want to configure. 

4. Fill in the fields as appropriate: 

• Host: Enter the hostname of the primary Websense Server. 

• Port: The default is 55805, but you can change it if the Websense Server is using a different 
port. 
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5. Repeat for the Alternate Websense Server. 

6. Click OK; click Apply. 

To Edit the Websense Client through the CLI 

1. At the (config) command prompt, configure the Websense client's primary or secondary server 
information: 

SGOS# (config) access-log 

SGOS# (config access-log) edit log log_name 

SGOS# (config log log_name) websense-client primary hostname [: port ] 

SGOS# (config log log_name) websense-client no primary 
-or- 

SGOS# (config log log_name) websense-client alternate hostname [-.port] 

SGOS# (config log log_name) websense-client no alternate 

where hostname specifies the primary or alternate server to which logs should be uploaded. 
By default the ProxySG uses port, which is 55805 by default. 

2. (Optional) To stop the log from being uploaded to a primary or secondary server in the future, 
clear the hostname by entering an empty string (that is, double-quotes) in the following 
command: 

SGOS# (config log log_name) websense-client primary "" 

-or- 

SGOS# (config log log_name) websense-client alternate "" 

3. (Optional) View the results. 

SGOS# (config log log_name) view 



929 



Blue Coat ProxySG Configuration and Management Guide 



Section H: Configuring the Upload Schedule 

Section H: Configuring the Upload Schedule 

The Upload Schedule allows you to configure the frequency of the access logging upload to a remote 
server, the time between connection attempts, the time between keep-alive packets, the time at which 
the access log is uploaded, and the protocol that is used. 

You can specify either periodic uploading or continuous uploading. Both periodic and continuous 
uploading can send log information from a ProxySG farm to a single log analysis tool. This allows you 
to treat multiple ProxySG appliances as a single entity and to review combined information from a 
single log file or series of related log files. 

With periodic uploading, the ProxySG transmits log entries on a scheduled basis (for example, once 
daily or at specified intervals) as entries are batched, saved to disk, and uploaded to a remote server. 



Note: When you configure a log for continuous uploading, it continues to upload until you stop 

it. To stop continuous uploading, switch to periodic uploading temporarily. This is 
sometimes required for gzip or encrypted files, which must stop uploading before you 
can view them. 



With continuous uploading, the ProxySG continuously streams new access log entries from the 
ProxySG memory to a remote server. Here, streaming refers to the real-time transmission of access log 
information. The ProxySG transmits access log entries using the specified client, such as FTP client. A 
keep-alive is sent to keep the data connection open. 

Continuous uploading allows you to view the latest logging information almost immediately, send 
log information to a log analysis tool for real-time processing and reporting, maintain ProxySG 
performance by sending log information to a remote server (avoiding disk writes), and save ProxySG 
disk space by saving log information on the remote server. 

If the remote server is unavailable to receive continuous upload log entries, the ProxySG saves the log 
information on the ProxySG disk. When the remote server is available again, the appliance resumes 
continuous uploading; however, when the stream is restarted, logs held on the hard disk drive are not 
sent. 



Note: If you do not need to analyze the upload entries in real time, use periodic uploading 

because it is more reliable than continuous uploading. 

If there is a problem configuring continuous uploading to Microsoft Internet Information 
Server (IIS), use periodic uploading instead. 



To Configure the Upload Schedule through the Management Console 
1. Select Configuration>Access Logging>Logs>Upload Schedule. 
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Logs | General Settings 
Log: 



Upload Client 



Upload Schedule 



- Upload type: 

Upload the access log 

O continuously ® periodically 

Wait between connect attempts: 60 seconds 

Time between keep-alive log packets: |3QQ [ seconds 



Upload the log file: 
® Daily at 



2:00 a.m. 



Upload No 



O Every 8 



|hours [~Q 



minutes 



Cancel Upload 



Figure 20-16: Upload Schedule Tab 



2. From the Log drop-down list, choose the log whose schedule you are configuring. 

3. Select an upload method by selecting continuously or the periodically; click Apply. 

4. To change the time between connection attempts, enter the new time (in seconds) in the Wait 
between connect attempts field. 



5. (Only accessible if you are updating continuously) To change the time between keep-alive 
packets, enter the new time (in seconds) in the Time between keep-alive log packets field. 

Keepalives maintain the connection during low periods of system usage. When no logging 
information is being uploaded, the ProxySG sends a keep-alive packet to the remote server at the 
interval you specify, from 1 to 65535 seconds. If you set this to 0 (zero), you effectively disable the 
connection during low usage periods. The next time that access log information needs to be 
uploaded, the ProxySG automatically reestablishes the connection. 

6. (Optional) From the Daily at drop-down list, specify the time of day you want the access log 
updated or rotated (if you are doing continuous uploads). 

7. (Optional) If you do not want the log uploaded or rotated on a daily basis, select Every and enter 
the time between uploads. 

Log rotation helps prevent logs from growing excessively large. Especially with a busy site, logs 
can grow quickly and become too big for easy analysis. With log rotation, the ProxySG 
periodically creates a new log file, and archives the older one without disturbing the current log 
file. 



8. (Optional) You can upload the access logs now or you can cancel any access-log upload currently 
in progress (if you are doing periodic uploads). You can rotate the access logs now (if you are 
doing continuous uploads). These actions do not affect the next scheduled upload time. 

Cancel upload (for periodic uploads) allows you to stop repeated upload attempts if the Web server 
becomes unreachable while an upload is in progress. Clicking this sets log uploading back to idle 
if the log is waiting to retry the upload. If the log file is in the process of uploading, it takes time 
for it to take effect. 



9. Click OK; click Apply. 
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To Configure an Upload Schedule through the CLI 

1. From the (config) command prompt, enter the following commands. 

SGOS# (config access-log) edit log log_name 

SGOS# (config log log_name) upload-type {gzip | text} 

2. Configure either a continuous upload schedule or a periodic upload schedule by using the 
options in the continuous-upload or periodic-upload commands. 



Note: If you are configuring a SurfControl upload client you must use periodic-upload, not 

continuous-upload. If you configure a Websense upload client, you should set it to 
continuous-upload. 



SGOS# (config log log_name) continuous -upload {enable | keep-alive seconds \ 
lag-time seconds | rotate-remote {daily 0-23 | hourly hours [minutes]}} 

-or- 

SGOS# (config log name) periodic-upload {enable | upload-interval {daily 0-23 \ 
hourly hours [ minutes ] } } 



where 



upload-type 


gzip | text 


Specifies using a compressed file (gzip) or a 
text file for uploading. 


continuous - 
upload 


enable 


Specifies continuous upload (automatically 
disables periodic upload). 




keep-alive seconds 


Specifies the interval between keep-alive log 
packets. Acceptable values are between 0 and 
65535 seconds. 




lag-time seconds 


Specifies the maximum time between log 
packets (text upload only). Acceptable values 
are between 0 and 65535 seconds. 

This setting configures the maximum time 
between text log packets, meaning that it 
forces a text upload after the specified length 
of time even if the internal log buffer is not 
full. If the buffer fills up before the time 
specified in this setting, the text uploads right 
away, and is not affected by this maximum 
setting. 




rotate-remote {daily 
0-23 | hourly hours 
[minutes] } 


Specifies when to rotate to new remote log file: 
enter the time of day for a daily rotation or 
enter how often to rotate (every n 
hours /minutes) for an hourly rotation. To 
rotate more than once an hour, enter 0 hours 
and specify n minutes. 


per iodic -upload 


enable 


Specifies periodic upload (automatically 
disables continuous upload). 



932 



Chapter 20: Access Logging 



Section H: Configuring the Upload Schedule 



upload- interval {daily 
0-23 | hourly hours 
[ minutes ] } 



Specifies when to upload a log file: enter the 
time of day for a daily upload or enter how 
often to upload (every n hours/ minutes) for 
an hourly upload. To upload more than once 
an hour, enter 0 hours and specify n minutes. 



3. Specify the time between connection attempts between the Proxy SG and the remote server: 
SGOS# (config log log_name ) connect-wait-time seconds 



4. 



(Optional) Use the following options to upload an access log immediately, to cancel an access log 
upload, to switch immediately to a new remote log file, or to permanently delete all access logs on 
the ProxySG: 



SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 



log 


log_ 


name ) 


commands 


upload-now 


log 


log_ 


name) 


commands 


cancel -upload 


log 


log_ 


name) 


commands 


rotate -remote -log 


log 


log_ 


name) 


commands 


delete- logs 



Ordinarily, the ProxySG automatically deletes the local copies of access logs from the ProxySG 
after the logs have been uploaded. You can manually delete access logs from the ProxySG, but it is 
not recommended. 



5. (Optional) View the results. 

SGOS# (config log log_name) view 

6. (Optional) To delete an individual log: 

SGOS# (config) access-log 

SGOS# (config access-log) delete log log_name 



Testing Access Log Uploading 

For the duration of the test, configure the event log to use the verbose event level (see "Configuring 
Which Events to Log" on page 951). This logs more complete log information. After you test 
uploading, you can check the event log through the Management Console for the test upload event 
and determine whether any errors occurred (go to Statistics>Event Logging). You cannot check the event 
log through the CLI. 

To Test Access Log Uploading through the Management Console 

You can do a test access log upload. Before you begin, make sure you have configured the upload 
client completely. 

1. Select Configuration>Access Logging>Logs>Upload Client. 

2. Click Test Upload. 

The Test upload dialog appears. 

3. Click OK in the Test upload dialog. 

4. Check the event log for upload results: go to Statistics>Event Logging. 



933 



Blue Coat ProxySG Configuration and Management Guide 



Section H: Configuring the Upload Schedule 



To Test Access Log Uploading through the CLI 



For the duration of the test, configure the event log to use the verbose event level. This logs more 
complete log information. After you test uploading, you can check the event log under the Statistics 
tab for the test upload event and determine whether any errors occurred. 

1. At the (config) command prompt, enter the following commands: 

SGOS# (config) access-log 

SGOS# (config access-log) edit log log_name 
SGOS# (config log log_name) commands test-upload 

2. In the Management Console, select Statistics>Event Logging. 

3. Click the forward arrow and back arrow buttons to move through the event list. 

4. Locate the following event log message entry: Access Log : Transfer complete. 

If you do not see the message, check for other Access Log messages from the appropriate time 
frame. Use these to help in troubleshooting. 

5. To check for a successful test upload at the remote server, locate the file logname_upload_result 
or, for an encrypted test upload, locate the file logname_upload_result . enc. If you locate the 
file, the test was successful. 

If you cannot locate the file, use the steps above to open the ProxySG event log, locate the test 
upload event, and determine whether any errors occurred. 



The following is a sample of the test file contents. 

******************** START OF TEST FILE ******************** 



NOTE: This is a verification file sent to test access log uploading. 
Please check the file for correctness and the event log for errors. 
For security purposes, please delete this file after perusal. 



ProxySG Appliance Date: 
ProxySG Appliance Time: 
ProxySG Appliance Name: 
ProxySG Appliance IP: 
ProxySG Appliance Type: 



2003-04-05 
02:17:23 UTC 

10.25.36.47 - Blue Coat SG800 

10.25.36.47 

Blue Coat SG800 



Sent to FTP server using the following configuration: 

Host: 10.25.45.35 

Port: 21 

Path : 

User: joe 

Password: ***** 

This file should contain approx. 819 bytes 

******************** end of test file ******************** 



Viewing Access-Log Statistics 

Access-log statistics can be viewed from the Management Console Statistics>Access Logging tab or the 
CLI show access-log statistics [ log_name ] command. See "Access-Log Statistics" on page 1013 
for information. 
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Using Access Logging with Policy Rules 

After configuration is complete, you must create rules to manage the access logs you set up. You can 
create rules through the Visual Policy Manager module of the Management Console, or you can use 
Content Policy Language (CPL) directly (refer to the Blue Coat ProxySG Content Policy Language Guide). 

Actions you can do to manage access logging: 

□ Reset logging to its default 

□ Disable all logging 

□ Add logging to a log file 

□ Disable logging to a log file 

□ Override specific access-log fields 

You can also set the list of logs to be used, but you must use CPL to create this action. It is not available 
through VPM. 

The first two actions — reset logging to its default and disable all logging — are referred to as constant 
actions, just like the allow/ deny actions. Select only one per rule. 

All of the actions are allowed in all layers. If you use VPM, the access-logging actions display in the 
VPM policy; if you use CPL, you can put the actions into any file, but Blue Coat recommends you use 
the Local file. 



Example: Using VPM to Prevent Entries Matching a Source IP Address 
from Being Logged 

Complete the following steps to prevent a source IP address from being logged. 

To Prevent a Source IP Address from Being Logged: 

1. Create a Web Access Layer: 

• Select Configuration>Policy>Visual Policy Manager; click Launch. 

• Select Policy>Add Web Access Layer from the menu of the Blue Coat VPM window that appears. 




Figure 20-17: Select Add Web Access Layer 

Type a layer name into the dialog that appears and click OK. 
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2. Add a Source object: 

• Right click on the item in the Source column; select Set. The Set Source dialog appears. 

• Click New; select Client IP Address/Subnet. 



File Edit Policy Configuration View Help 



Add Rule 



“p Delete Rule 



Move Up 



4- Move Down 



Install Policy 



Web Access Layer Test 




Figure 20-18: Select Client IP Address/Subnet 



• Enter an IP address or Subnet Mask in the dialog that appears and click Add; click Close (or 
add additional addresses and then click Close); click OK. 



3. Add an Action object to this rule: 

• Right-click on the item in the Action column; select Set. 
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File Edit Policy Configuration View Help 


%) Add Rule Delete Rule 4 Move Up 4 Move Down Install Policy 


Web Access Layer Test 


No. | Source | Destination | Service | Time Action | Track | Comment 


1 §i|l Client: 1... Any |Any Any QI»UiM 


H 

Allow 

Deny 

Delete 

Negate 

Cut 

Copy 

Paste 









Figure 20-19: Right-Click Action and Select Set 
• Click New in the Set Action Object dialog that appears; select Modify Access Logging. 



File Edit Policy Configuration View 


Help 








%| Add Rule 


“□ Delete Rule 


1 ■ Move Up 


4 - Move Down 


Install Policy 




Web Access Layer Test 





No. 



Source 



Destination 



Service 



Time 



1 Client: 1 



Action 



Track 



Comment 



S3 Set Action Object 



Existing Action Objects 



xj 



Show: [AM 



~3 



© Deny 
^ Force Deny 
£ Bypass Cache 
2 Do not Bypass Cache 
m Check Authorization 

Do not Check Authorization 
Always Verity 

a Use Default Verification 



New... 



Deny ... 

Return Exception.. 

Return Redirect... 

Send IM Alert... 

lEUZS 

Override Access Log Field 
Rewrite Host... 

Figure 20-20: Disable Access Logging 



U 



Help 



To disable a particular log, click Disable logging to and select that log from the drop-down list; 
to disable all access logging, click Disable all access logging. 
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• Click OK; click OK again; close the VPM window and click Yes in the dialog to save your 
changes. 
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The Maintenance tabs provide a set of tools for managing and configuring an array of system-wide 
parameters, such as restarting the ProxySG, restoring system defaults, configuring SNMP, and 
managing the ProxySG. 

This chapter contains the following sections: 

□ "Restarting the ProxySG" on page 939 

n "Restoring System Defaults" on page 941 

□ "Purging the DNS Cache" on page 944 

□ "Clearing the System Cache" on page 944 

□ "Upgrading the ProxySG" on page 945 

D "Managing ProxySG Systems" on page 948 

□ "Event Logging and Notification" on page 951 

□ "Configuring SNMP" on page 957 

□ "Configuring Health Monitoring" on page 960 

□ "Disk Reinitialization" on page 970 

□ "Deleting Objects from the ProxySG" on page 971 

Restarting the ProxySG 

The restart options control the restart attributes of the ProxySG if a restart is required because of a 
system fault. 

Important: The default settings of the Restart option suits most systems. Changing them without 
assistance from Blue Coat Systems Technical Support is not recommended. 



Hardware and Software Restart Options 

The Restart settings determine if the ProxySG performs a faster software-only restart, or a more 
comprehensive hardware and software restart. The latter can take several minutes longer, depending 
upon the amount of memory and number of disk drives in the ProxySG. 

The default setting of Software only suits most situations. Restarting both the hardware and software is 
recommended in situations where a hardware fault is suspected. 

For information about the Core Image settings, see "Core Image Restart Options" on page 1136. 
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Note: If you change restart option settings and you want them to apply to the next ProxySG 

restart, click Apply. 



To Restart the ProxySG through the Management Console 

1. Select Maintenance>General. 

General 

- Restart 

(•) Software only System to run: 

O Hardware and software | Restart now ] 

- T asks 

| Restore ] the configuration to defaults. 

Purge | the DNS cache. 

Cleat ~| the system cache. 

Figure 21 -1 : Restarting the ProxySG 

2. In the Restart field, select either Software only or Hardware and software. 

3. If you select the Hardware and software option, select a system from the System to run drop-down 
list. 

The default system is pre-selected. 

4. Click Apply. 

5. Click Restart now. 

6. Click OK to confirm and restart the ProxySG. 

To Configure the Hardware/Software Restart Settings through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) restart mode {hardware | software} 



where: 



hardware 


Configures the ProxySG for hardware (and software) restart. 


software 


Configures the ProxySG for software only restart. 



To Restart the ProxySG through the CLI 

Do one of the following: 

□ To restart the system according to the restart settings, enter the following command: 
SGOS# restart regular 
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□ To restart hardware and software with a full core image, enter the following command: 

SGOS# restart abrupt 

□ If you have added a new software image and want to restart the system using that image, enter 
the following command: 

SGOS# restart upgrade 

Restoring System Defaults 

The ProxySG allows you to restore some or all of the system defaults. Use these commands with 

caution. The restore-defaults command deletes most, but not all, system defaults: 

□ The restore-defaults command with the factory-defaults option reinitializes the ProxySG 
to the original settings it had when it was shipped from the factory. 

□ The restore-defaults command with the keep-console option allows you to restore default 
settings without losing all IP addresses on the system. 

Restore- Defaults 

Settings that are deleted when you use the restore-defaults command include: 

□ All IP addresses (these must be restored through the CLI before you can access the Management 
Console again). 

□ DNS server addresses (these must be restored through the CLI before you can access the 
Management Console again). 

□ Installable lists. 

□ All customized configurations. 

□ Third-party vendor licenses, such as SmartFilter or Websense. If you use the restore-defaults 
command after you have installed licenses, and the serial number of your system is configurable 
(older boxes only), the licenses fails to install and the ProxySG returns to the trial period (if any 
time is left). To correct the problem, you must configure your serial number and install your 
license-key again. 

□ Blue Coat trusted certificates. 

□ Original SSH (vl and v2) host keys (new host keys are regenerated). 

You can use the force option to restore defaults without confirmation. 

Factory- Defaults 

All system settings are deleted when you use the restore-defaults command with the 

factory-defaults option. 

The only settings that are kept when you use the restore-defaults command with the 

factory-defaults option are: 

□ Trial period information. 

□ The last five installed appliance systems, from which you can pick one for rebooting. 
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The Setup Console password is also deleted if you use restore-defaults factory-defaults. For 
information on the Setup Console password, see "Securing the Serial Port" on page 312. 

You can use the force option to restore defaults without confirmation. 

Keep-Console 

Settings that are retained when you use the restore-defaults command with the keep-console 
option include: 

□ IP addresses, including default gateway and bridging, except for virtual IP addresses). 

□ Ethernet maximum transmission unit (MTU) size. 

□ TCP round trip time. 

□ Static routes table information. 

Using the keep-console option retains the settings for all consoles (Telnet, SSPI, PITTP, and PITTPS), 
whether they are enabled, disabled, or deleted. Administrative access settings retained using the 
restore-defaults command with the keep-console option include: 

□ Console username and password. 

□ Front panel pin number. 

□ Console enable password. 

□ SSPI (vl and v2) host keys. 

□ Keyrings used by secure console services. 

□ RIP configurations. 

You can also use the force option to restore defaults without confirmation. 

To Restore System Defaults through the Management Console 

Note: The keep-console and factory-defaults options are not available through the 

Management Console. 



1. Select Maintenance>General. 
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General 

- Restart 

(♦) Software only System to run: 

O Hardware and software 

- T asks 

[ Restore ] the configuration to defaults. 

Purge | the DNS cache. 

Clear ] the system cache. 

Figure 21-2: Restoring System Defaults 

2. From the Tasks field of the General Tab, click Restore the configuration to defaults. If you restore the 
configuration from the Management Console, most settings are lost because you cannot use the 
keep-console option. 

The Restore Configuration dialog appears. 



Reset configuration 



4 



Restart now 



Confirmation required 

ARE YOU SURE YOU WANT TO RESET THE SYSTEM CONFIGURATION? 
This will clear most system settings and erase the access log 

Press "OK" to reset the configuration and restart the system. 



| OK | | Cancel ] 

Figure 21-3: Reset Configuration Confirmation 
3. Click OK. 

To Restore System Defaults through the CLI 

At the command prompt, enter the following command: 
SGOS# restore-defaults [keep-console] 

To Restore System Defaults without Confirmation: 

At the command prompt, enter the following command: 
SGOS# restore-defaults [keep-console] force 

To Restore Factory Defaults through the CLI 

At the command prompt, enter the following command: 
SGOS# restore-defaults factory-defaults 
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Purging the DNS Cache 

You can purge the DNS cache at any time. You might need to do so if you have experienced a problem 
with your DNS server or if you have changed your DNS configuration. 

To Purge the DNS Cache through the Management Console 

1. Select Maintenance>General. 

2. In the Tasks field, click Purge. 

3. Click OK to confirm in the Purge system DNS cache dialog that appears. 




Figure 21-4: Purging the DNS Cache 
To Purge the DNS Cache through the CLI 

At the enable command prompt, enter the following command: 

SGOS# purge -dns- cache 

Clearing the System Cache 

You can clear the system cache at any time. 

When you clear the cache, all objects in the cache are set to expired. The objects are not immediately 
removed from memory or disk, but a subsequent request for any object requested is retrieved from the 
source before it is served. 

To Clear the System Cache through the Management Console 

1. Select Maintenance>General. 

2. In the Tasks field, click Clear. 

3. Click OK to confirm in the Clear cache dialog that appears. 
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Figure 21-5: Clearing the System Cache 

To Clear the System Cache through the CLI 

At the enable command prompt, enter the following command: 

SGOS# clear-cache 

Troubleshooting Tip 

Occasionally, the Management Console might behave incorrectly because of browser caching, 
particularly if the browser was used to run different versions of the ProxySG Management Console. 
This problem might be resolved by clearing the browser cache. 

Upgrading the ProxySG 

When an upgrade to the ProxySG becomes available, you can download it through the Internet and 
install it. You can also download it to your PC and install it from there. 



Important: Enable the auto-detect encoding feature on your browser so that it uses the encoding 
specified in the console URLs. The browser does not use the auto- detect encoding 
feature by default. If auto-detect encoding is not enabled, the browser ignores the 
charset header and uses the native OS language encoding for its display. 



The ProxySG 4.x Version Upgrade 

The appliance must be running version SGOS 3.2.4 or later in order to upgrade to SGOS 4.x. You 
cannot directly upgrade from any previous version. 

When upgrading from the SGOS 3.2.4 or higher release, a copy of the settings is saved before any 
transformations by SGOS 4.x so that the original settings are available if the ProxySG is downgraded 
to SGOS 3.2.x. Any changes made to the system when it is running SGOS 4.x are not reflected in the 
saved copy of the original settings. Any changes made when running the previous operating systems 
after upgrading once to SGOS 4.x are not reflected in the SGOS 4.x settings when the system is 
re-upgraded to SGOS 4.x. In other words, the upgrade process only happens one time between SGOS 
3.2.4 and SGOS 4.x. You can override this behavior by using the load upgrade [ignore-warnings] 
command. For information on using the this command, see "To Upgrade the ProxySG through the 
CLI" on page 947. 
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Note: At least one other system must be unlocked to do the upgrade. If all systems are locked, 

or all systems except the running system are locked, the Download button in the 
Management Console is disabled. Similarly, the load upgrade command in the CLI 
generates an error. 



To Upgrade the ProxySG through the Management Console 
1. Select Maintenance>Upgrade>Upgrade. 



Upgrade Systems 



Download new system software from this URL: 



| http: //buildser ver-1 . bluecoat. com/builds/sg_4_2. 241 30/wdir/1 1 0 . d | Download 



Replace: 



oldest unlocked system 



- Upgrade actions 

Show me ] the ProxySG Appliance systems available for download. 



Upload the system image from local file. 



Restart ] the default system. 

Figure 21-6: Upgrading the ProxySG 



2. Click Show me to connect to the Blue Coat download page, follow the instructions, and note the 
URL of the ProxySG upgrade for your system model. Then enter the URL in the Download new 
system software from this URL field and click Download. 



-or- 

(Only if you previously downloaded a system image to your PC) Click Upload and Browse to the 
file location, then click Install. The upload might take several minutes. 
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Upload and Install File 



Upload and Install the System Image 

1 . Paste the file path into the box below or choose a file 
by clicking the Browse... button and opening the file. 

2. Click Install to upload and install the new file. It can 
take some time for the upload to complete. Your 
browser may be unresponsive during the upload. 

3. Once the installation is completed the results will be 
displayed in a new page. Close the results page once 
you have finished viewing the results. 



BlueOCoat 

Systems 




File to upload: 

|C:\Documents and Settings\3000.CHK_dbg Browse... | 



Install | 



Close | 



Figure 21-7: Uploading a System Image from a PC 



3. (Optional) Select the system to replace in the Replace drop-down list. If you uploaded an image 
from your PC, refresh the Systems pane to see the new system image. 

4. Click Restart. 



The Restart system dialog displays. 



Restart system 






- Restart system 

ARE YOU SURE YOU WANT TO RESTART THE SYSTEM? 
Press "OK" to initiate the restart sequence. 



OK | ( Cancel | 

Figure 21-8: Restart System Dialog 

5. Click OK to reboot the ProxySG to the default system. 



To Upgrade the ProxySG through the CLI 

From the serial console, enter the following commands: 

SGOS# (config) upgrade -path url 

where url is the location of the SGOS upgrade image. 

SGOS# (config) exit 

SGOS# load upgrade [ignore -warnings] 

where ignore -warnings allows you to force an upgrade even if you receive policy 
deprecation warnings. Using the load upgrade ignore-warnings command to force an 
upgrade while the system emits deprecation warnings results in a policy load failure; all 
traffic is allowed or denied according to default policy. 
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SGOS# restart upgrade 



Managing ProxySG Systems 

The ProxySG Systems tab displays the five available ProxySG systems. Empty systems are indicated 
by the word Empty. 

The ProxySG system currently running is highlighted in blue and cannot be replaced or deleted. 
From this screen, you can: 

□ Select the SGOS system version to boot. 

□ Lock one or more of the available SGOS system versions. 

□ Select the SGOS system version to be replaced. 

□ Delete one or more of the available SGOS system versions (CLI only). 

□ View details of the available SGOS system versions. 

To View ProxySG System Replacement Options through the Management Console 
Select Maintenance>Upgrade>Systems. 



Upgrade Systems 

ProxySG Appliance Systems ■ 



System Version 

1: SGOS 4.1. 3.1, Release ID: 23960~ 



Lock Replace Default 



2: SGOS 96 . 99. 99. 99, R elease ID; 23996 Debi. 



3: SGOS 4.20.7, Release ID: 24119 D ebug 

4: I SGOS 4.20.7. Release ID: 24130 Debug 



5: [ Empty 



0 


□ 


o 


| Details 


□ 


□ 


o 


| Details 


□ 


□ 


O 


[ Details 


□ 


□ 


© 


[ Details 

1 Details 



Figure 21-9: Setting SGOS System Version Replacement Properties 



To View Details for an SGOS System Version through the Management Console 

1. Select Maintenance>Upgrade>Systems. 

2. Click Details next to the system for which you want to view detailed information; click OK when 
you are finished. 



System Information 






- Detailed System Information 

Version: SGOS 4.1. 3.1, Release ID: 23960 

Creation date: Wednesday November 2 2005 10:23:53 UTC 

Boot Status: Last boot succeeded 

Last Successful Boot: Wednesday November 2 2005 20:31 :53 UTC 



1 0* I 

Figure 21-10: SGOS System Version Details 
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To View Details for an SGOS System Version through the CLI 

At the command prompt: 

SGOS> show installed- systems 



Example Session 

SGOS> show installed- systems 

ProxySG Appliance Systems 

1. Version: SGOS 4. 1.3.1, Release 
Wednesday November 2 2005 10:23:53 
Boot Status: Last boot succeeded, 
2005 20:31:53 UTC 

2. Version: SGOS 4. 2. 0.7, Release 
Tuesday November 15 2005 09:48:25 
Boot Status: Last boot succeeded, 
2005 18:33:08 UTC 

3. Version: SGOS 4. 2. 0.7, Release 
Tuesday November 15 2005 21:50:26 
Boot Status: Last boot succeeded, 
2005 00:33:32 UTC 

4. Version: SGOS 4. 2. 0.7, Release 
Tuesday November 29 2005 10:00:50 
Boot Status: Last boot succeeded, 
005 19:43:56 UTC 



ID: 23960 

UTC, Lock Status: Unlocked 
Last Successful Boot : Wednesday November 2 

ID: 24119 Debug 

UTC, Lock Status: Unlocked 

Last Successful Boot: Tuesday November 15 

ID: 24130 Debug 

UTC, Lock Status: Unlocked 

Last Successful Boot: Wednesday November 23 

ID: 24244 Debug 

UTC, Lock Status: Unlocked 

Last Successful Boot: Tuesday November 29 2 



Default system to run on next hardware restart : 4 
Default replacement being used, (oldest unlocked system) 

Current running system: 4 

When a new system is loaded, only the system number that was replaced is 
changed. The ordering of the rest of the systems remains unchanged. 



Setting the Default Boot System 

This setting allows you to select the system to be booted on the next hardware restart. If a system starts 
successfully, it is set as the default boot system. If a system fails to boot, the next most recent system 
that booted successfully becomes the default boot system. 

To Set the ProxySG to Run on the Next Hardware Restart through the Management Console 

1. Select Maintenance>Upgrade>Systems. 

2. Select the preferred ProxySG System version in the Default column. 

3. Click Apply. 



Note: An empty system cannot be specified as default, and only one system can be specified as 

the default system. 



To Set the ProxySG to Run on the Next Hardware Restart through the CLI 

At the (config) command prompt: 
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SGOS# (config) installed- systems 

SGOS# (config installed- systems ) default system_number 
where system_number is the default system version. 

Locking and Unlocking ProxySG Systems 

Any system can be locked, except a system that has been selected for replacement. If all systems, or all 
systems except the current system are locked, the ProxySG cannot load a new system. 

If a system is locked, it cannot be replaced or deleted. 

To Lock a System through the Management Console 

1. Select Maintenance>Upgrade>Systems. 

2. Select the system(s) to lock in the Lock column. 

3. Click Apply. 

To Lock a System through the CLI 

At the (config) command prompt, enter the following commands: 

SGOS# (config) installed- systems 

SGOS# (config installed- systems ) lock system_number 
where system_number is the system you want to lock. 

To Unlock a System through the Management Console 

1. Select Maintenance>Upgrade>Systems. 

2. Deselect the system(s) to unlock in the Lock column. 

3. Click Apply. 

To Unlock a System through the CLI 

At the (config) command prompt, enter the following commands: 

SGOS# (config) installed- systems 

SGOS# (config installed- systems ) no lock system_number 
where system_number is the system you want to unlock. 

Replacing a ProxySG System 

You can specify the system to be replaced when a new system is downloaded. If no system is 
specified, the oldest unlocked system is replaced by default. You cannot specify a locked system for 
replacement. 

To Specify the System to Replace through the Management Console 

1. Select Maintenance>Upgrade>Systems. 

2. Select the system to replace in the Replace column. 

3. Click Apply. 
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To Specify the System to Replace through the CLI 

At the (config) command prompt, enter the following commands: 

SGOS# (config) installed- systems 

SGOS# (config installed- systems ) replace system_number 
where system_number is the system to be replaced. 

Deleting a ProxySG System 

You can delete any of the ProxySG system versions except the current running system. A locked 
system must be unlocked before it can be deleted. If the system you want to delete is the default boot 
system, you need to select a new default boot system before the system can be deleted. 

You cannot delete a system version through the Management Console; you must use the CLI. 

To Delete a System through the CLI 

At the (config) command prompt, enter the following commands: 

SGOS# (config) installed- systems 

SGOS# (config installed-systems) delete system_number 
where system_number is the system you want to delete. 

Event Logging and Notification 

You can configure the ProxySG to log system events as they occur. Event logging allows you to specify 
the types of system events logged, the size of the event log, and to configure Syslog monitoring. The 
ProxySG can also notify you by e-mail if an event is logged. 

Configuring Which Events to Log 

The event level options are listed from the most to least important events. Because each event requires 
some disk space, setting the event logging to log all events fills the event log more quickly. 

To Set the Event Logging Level through the Management Console 

1. Select Maintenance>Event Logging>Level. 

Level | Size | Mail | Syslog 

- Event logging level: 

0 Severe errors 
0 Configuration events 
0 Policy messages 
0 Informational 
| | Verbose 

Figure 21-11: Selecting Which Events are Logged 

2. Select the events you want to log. 
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When you select an event level, all levels above the selection are included. For example, if you 
select Verbose, all event levels are included. 

3. Click Apply. 

To Set the Event Logging Level through the CLI 

At the (config) command prompt, enter the following commands: 

SGOS# (config) event-log 

SGOS# (config event-log) level {severe | configuration | policy | 
informational | verbose} 



where: 



severe 


Writes only severe error messages to the event log. 


configuration 


Writes severe and configuration change error messages to the event log. 


policy 


Writes severe, configuration change, and policy event error messages to the 
event log. 


informational 


Writes severe, configuration change, policy event, and information error 
messages to the event log. 


verbose 


Writes all error messages to the event log. 



Setting Event Log Size 

You can limit the size of the ProxySG's event log and specify what the appliance should do if the log 
size limit is reached. 

To Set Event Log Size through the Management Console 
1. Select Maintenance>Event Logging>Size. 

Level Size | Mail | Syslog 

- Event log size: 

Limit event log to j 1 0 megabytes of disk space 



- When event log reaches maximum size: 

® Overwrite earlier events 
O Stop logging new events 

Figure 21-12: Configuring Event Log Size 

2. In the Event log size field, enter the maximum size of the event log in megabytes. 

3. Select either Overwrite earlier events or Stop logging new events to specify the desired behavior when 
the event log reaches maximum size. 

4. Click Apply. 



952 



Chapter 21 : Maintaining the ProxySG 



To Set Event Log Size through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) event-log 

SGOS# (config event-log) log-size megabytes 

SGOS# (config event-log) when-full {overwrite | stop) 

Specifies event logging behavior should the event log become full. 

Enabling Event Notification 

The ProxySG can send event notifications to Internet e-mail addresses using SMTP. You can also send 
event notifications directly to Blue Coat for support purposes. For information on configuring 
diagnostic reporting, see Appendix E: "Diagnostics" on page 1121. 



Note: The ProxySG must know the host name or IP address of your SMTP mail gateway to mail 

event messages to the e-mail address(es) you have entered. If you do not have access to an 
SMTP gateway, you can use the Blue Coat default gateway to send event messages 
directly to Blue Coat. 



The Blue Coat SMTP gateway only sends mail to Blue Coat. It will not forward mail to other 
domains. 

To Enable Event Notifications through the Management Console 
1. Select Maintenance>Event Logging>Mail. 

Level | Size Mail | Syslog 

r Mail notifications to: 




0 SMTP gateway IP: 



0 Clear SMTP gateway settings 

Figure 21-13: Enabling Event Notification 

2. Click New to add a new e-mail address; click OK in the Add list item dialog that appears. 

3. In the SMTP gateway name field, enter the host name of your mail server; or in the SMTP gateway IP 
field, enter the IP address of your mail server. 

4. (Optional) If you want to clear one of the above settings, select the radio button of the setting you 
want to clear. You can clear only one setting at a time. 
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5. Click Apply. 

To Enable Event Notifications through the CLI 

At the (config) command prompt, enter the following commands: 

SGOS# (config) event-log 

SGOS# (config event-log) mail smtp-gateway gateway 

where gateway is a domain name or an IP address. 

SGOS# (config event-log) mail add recipient@url 
SGOS# (config event-log) exit 
SGOS# (config) policy notify 

Sends event notifications directly to Blue Coat for support purposes. 

Syslog Event Monitoring 

Syslog is an event-monitoring scheme that is especially popular in UNIX environments. Sites that use 
syslog typically have a log host node, which acts as a sink (repository) for several devices on the 
network. You must have a syslog daemon operating in your network to use syslog monitoring. The 
syslog format is: Date Time Hostname Event. 

Most clients using syslog have multiple devices sending messages to a single syslog daemon. This 
allows viewing a single chronological event log of all of the devices assigned to the syslog daemon. 
An event on one network device might trigger an event on other network devices, which, on occasion, 
can point out faulty equipment. 

To Enable Syslog Monitoring through the Management Console 

1. Select Maintenance>Event Logging>Syslog. 

Level | Size | Mail Syslog 

- Syslog configuration 

Loghost: | J 

□ Enable syslog 

Figure 21-14: Setting Up Syslog Monitoring 

2. In the Loghost field, enter the domain name or IP address of your loghost server. 

3. Select Enable Syslog. 

4. Click Apply. 

To Enable Syslog Monitoring through the CLI 

At the (config) command prompt, enter the following commands: 

SGOS# (config) event-log 

SGOS# (config event-log) syslog loghost loghost 

where loghost is the log host domain name or IP address. 

SGOS# (config event-log) syslog enable 
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Viewing Event Log Configuration and Content through the CLI 

You can view the system event log through the CLI, either in its entirety or selected portions of it. 

Viewing the Event Log Configuration through the CLI 

You can view the event log configuration, from show or from view in the event-log configuration 
mode. 

To View the Event Log Configuration through the CLI 

At the prompt, enter the following command: 

□ From anywhere in the CLI 

SGOS> show event- log configuration 

Settings : 

Event level: severe + configuration + policy + informational 
Event log size: 10 megabytes 

If log reaches maximum size, overwrite earlier events 
Syslog loghost: <none> 

Syslog notification: disabled 
Syslog facility: daemon 
Event recipients: 

SMTP gateway: 

mail . heartbeat . bluecoat . com 



-or- 

CI From the (config) prompt: 

SGOS# (config) event-log 

SGOS# (config event-log) view configuration 
Settings : 

Event level: severe + configuration + policy + informational 
Event log size: 10 megabytes 

If log reaches maximum size, overwrite earlier events 
Syslog loghost: <none> 

Syslog notification: disabled 
Syslog facility: daemon 
Event recipients: 

SMTP gateway: 

mail . heartbeat . bluecoat . com 

Viewing the Event Log Contents through the CLI 

Again, you can view the event log contents from the show command or from the event-log 
configuration mode. 

The syntax for viewing the event log contents is 

SGOS# show event- log 

-or- 

SGOS# (config event-log) view 

[start [YYYY-mm-dd] [HH:MM:SS]] [end [YYYY-mm-dd] [HH:MM:SS]] [regex regex \ 
substring string ] 
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Pressing <Enter> shows the entire event log without filters. 

The order of the filters is unimportant. If start is omitted, the start of the recorded event log is used. 
If end is omitted, the end of the recorded event log is used. 

If the date is omitted in either start or end, it must be omitted in the other one (that is, if you supply 
just times, you must supply just times for both start and end, and all times refer to today). The time 
is interpreted in the current timezone of the ProxySG. 

Understanding the Time Filter 

The entire event log can be displayed, or either a starting date / time or ending date / time can be 
specified. A date/time value is specified using the notation ([YYYY-MM-DD] [HH:MM:SS]). Parts of 
this string can be omitted as follows: 

□ If the date is omitted, today's date is used. 

□ If the time is omitted for the starting time, it is 00:00:00 

□ If the time is omitted for the ending time, it is 23:59:59 

At least one of the date or the time must be provided. The date/ time range is inclusive of events that 
occur at the start time as well as dates that occur at the end time. 



Note: If the notation includes a space, such as between the start date and the start time, the 

argument in the CLI should be quoted. 



Understanding the Regex and Substring Filters 

A regular expression can be supplied, and only event log records that match the regular expression 
are considered for display. The regular expression is applied to the text of the event log record not 
including the date and time. It is case-sensitive and not anchored. You should quote the regular 
expression. 

Since regular expressions can be difficult to write properly, you can use a substring filter instead to 
search the text of the event log record, not including the date and time. The search is case sensitive. 

Regular expressions use the standard regular expression syntax as defined by policy. If both regex and 
substring are omitted, then all records are assumed to match. 
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Example 

SGOS# show event-log start "2004-10-22 9:00:00" end "2004-10-22 9:15:00" 

2004-10-22 09 : 00 : 02+00 : 00UTC "Snapshot sysinf o_stats has fetched 
/sysinfo-stats " 0 2D0006:96 . . /Snapshot_worker . cpp : 183 

2004-10-22 09 : 05 : 4 9+00 : 00UTC "NTP: Periodic query of server 

ntp.bluecoat.com, system clock is 0 seconds 682 ms fast compared to NTP time. 
Updated system clock. " 0 90000:1 . . /ntp . cpp : 631 

Configuring SNMP 

You can view a ProxySG using a Simple Network Management Protocol (SNMP) management station. 
The ProxySG supports MIB-2 (RFC 1213), Proxy MIB, and the RFC2594 MIB, and can be downloaded 
at the following URL: https://download.bluecoat.com/release/SGOS4/index.html (The SNMP link 
is in the lower right-hand corner.). 

Enabling SNMP 

To view a ProxySG from an SNMP management station, you must enable and configure SNMP 
support on the ProxySG. 

To Enable and Configure SNMP through the Management Console 

1. Select Maintenance>SNMP>SNMP General. 

SNMP General | Community Strings | Traps 

- General sellings: 

|~] Enable SNMP [ Resel SNMP sellings | 

- Values for MIB variables: 

sysLocation: 

sysConlacl: 

Figure 21-15: Enabling SNMP 

2. Select Enable SNMP. 

3. (Optional) To reset the SNMP configuration to the defaults, click Reset SNMP settings. This erases 
any trap settings that were set as well as any community strings that had been created. You do not 
need to reboot the system after making configuration changes to SNMP. 

4. In the sysLocation field, enter a string that describes the ProxySG's physical location. 

5. In the sysContact field, enter a string that identifies the person responsible for administering the 
ProxySG. 

6. Click Apply. 

To Enable and Configure SNMP through the CLI 

At the (config) command prompt, enter the following commands: 
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SGOS# (config) snmp 

SGOS# (config snmp) enable 

SGOS# (config snmp) sys-location location 

where location specifies the ProxySG's physical location. 

SGOS# (config snmp) sys-contact contact 

where contact identifies the person responsible for administering the ProxySG. 

Configuring SNMP Community Strings 

Use community strings to restrict access to SNMP data. To read SNMP data on the ProxySG, specify a 
read community string. To write SNMP data to the ProxySG, specify a zvrite community string. To receive 
traps, specify a trap community string. By default, all community string passwords are set to public. 



Note: If you enable SNMP, make sure to change all three community-string passwords to values 

that are difficult to guess. Use a combination of uppercase, lowercase, and numeric 
characters. An easily-guessed community-string password makes it easier to gain 
unauthorized access to the ProxySG and network. 



To Set or Change Community Strings through the Management Console 
1. Select Maintenance>SNMP>Community Strings. 

SNMP General Community Strings | Traps 




Figure 21-16: Configuring SNMP Community Strings 
2. Click the community string button you want to change. 

The Change Read/Write/Trap Community dialog displays. 




Figure 21-17: SNMP Change Community String Dialog 
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3. Enter and confirm the community string; click OK. 

4. Click Apply. 



To Set or Change Community Strings through the CLI 



You can set the community strings in either cleartext or encrypted form. 



To set them in cleartext: 



SGOS# (conf ig) snmp 
SGOS#(config snmp) 
SGOS# (conf ig snmp) 
SGOS# ( conf ig snmp) 
SGOS#(config snmp) 



enable 

read- community password 
write-community password 
trap -community password 



To set them as encrypted: 



SGOS# (conf ig) snmp 
SGOS# (conf ig snmp) 
SGOS# (conf ig snmp) 
SGOS# (conf ig snmp) 
SGOS# (conf ig snmp) 



enable 

encrypted -read -community encrypted -pas sword 
encrypted- write -community encrypted- pas sword 
encrypted- trap -community encrypted- pas sword 



Configuring SNMP Traps 

The ProxySG can send SNMP traps to a management station as they occur. By default, all system-level 
traps are sent to the address specified. Also, if the system crashes for whatever reason, a cold start 
SNMP trap is issued on power up. No configuration is required. 



Note: The SNMP trap for CPU utilization is sent only if the CPU continues to stay up for 32 or 

more seconds. 
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To Enable SNMP Traps through the Management Console 



Note: You cannot configure SNMP traps to go out through a particular interface. The interface 

that is configured first is used until it fails and is used to identify the device. 



1. Select Maintenance>SNMP>Traps. 

SNMP General | Community Strings Traps 

- T rap destinations: 

Send traps to: 



- T rap types: 

□ Enable authorization traps 

Figure 21-18: Configuring SNMP Traps 

2. In the Send traps to fields, enter the IP address(es) of the workstation(s) where traps are to be sent. 

3. To receive authorization traps, select Enable authorization traps. 

4. Click Apply. 

To Enable SNMP Traps through the CLI 

Note: You cannot configure SNMP traps to go out through a particular interface. 



1. At the (config) command prompt, enter the following commands: 

SGOS# (config) snmp 
SGOS# (config snmp) enable 

SGOS# (config snmp) trap-address 1 ip_address 

To add additional trap addresses, repeat using trap-address 2 or trap-address 3 to 
specify the IP address for traps 2 and 3. 

2. (Optional) To enable authorization traps, enter the following command: 

SGOS# (config snmp) authorize- traps 

Configuring Health Monitoring 

The health monitoring feature enhances the remote monitoring capabilities of the ProxySG. By 
monitoring key hardware and software metrics. Director (and other third-party network management 
tools) can provide administrators with a remote view of the health of the ProxySG system. 
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To facilitate prompt corrective action, notification can be configured for threshold "events." For 
example, an administrator can configure a threshold so that an e-mail or SNMP trap is generated 
when the threshold state changes. Additionally, many of the threshold levels are configurable so that 
you can adjust the thresholds to meet your specific requirements. 



1 




2 



Legend 

1 . Director queries the ProxySG for health metrics using the CLI. 

Figure 21-1: Health Monitoring Configuration and Notification Process 

As shown in the preceding figure, the ProxySG health monitoring metrics can be remotely configured 
and queried from Director. The metrics are also configurable on the ProxySG itself. 

Health Monitoring Requirements 

Before using the health monitoring feature you should do the following: 

□ Configure all management stations as trap destinations on the ProxySG. You must also configure 
the community string. 

□ Management stations must configure trap listeners for all monitored ProxySG systems. 

□ Obtain the SGOS MIBs: 

• System-resource 

• bluecoat-host 

• Disk 

• Sensor 

You can download the MIBs from the download page for your software release: 
http:/ / download.bluecoat.com/yoHr_so/fieflre_re/eflse/mibs.zip 
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In the preceding example, your_software_release is the OS release number of your software. 

For example, MIBs for SGOS 5 releases are located at 

http : / / download .bluecoat.com / release / SGOS5 / files / mibs .zip 

□ Ensure that the e-mail addresses of all persons that should be notified of health monitoring alerts 
are listed in the Event log properties. See "Event Logging and Notification” on page 951 for more 
information. 

About Hardware/Environmental Metrics (Sensors) 

The hardware and environmental metrics are referred to as sensors. Sensor threshold values are not 
configurable and are preset to optimal values. For example, if the CPU temperature reaches 55 degrees 
Celsius, it is considered to have entered the Warning threshold. The following table describes the 
sensor metrics. 



Note: See "Health Monitoring Requirements" on page 961 for information about obtaining MIBs 



Table 21.1: Sensor Health Monitoring Metrics 



Metric 


MIB 


Threshold States 


Disk status 


Disk 


Critical: 

Bad 

Warning: 

Not Present 
Removed 
Offline 
OK: 

Present 

Initializing 

Inserted 

Slot_empty 


Temperature 


Sensor 


High- critical 


Bus temperature 
CPU temperature 




High- warning 


Fan 


Sensor 


Critical: 


CPU Fan 




Low-critical 

Warning: 

Low-warning 



962 



Chapter 21 : Maintaining the ProxySG 



Table 21.1: Sensor Health Monitoring Metrics (Continued) 



Voltage 


Sensor 


Critical: 


Bus Voltage 




critical 


CPU voltage 




high- critical 


Power Supply voltage 




low-critical 
Warning: 
high -warning 
low-warning 



About System Resource Metrics 

The following table lists the ProxySG system resource metrics. The thresholds for these metrics are 
user-configurable. See "About Health Monitoring Thresholds" on page 964 for information about 
thresholds and alert notification. 

All of the system resource metrics are described in the System-resource MIB. See "Health Monitoring 
Requirements" on page 961 for information about obtaining MIBs. 

All threshold intervals are in seconds (licensing expiration intervals are ignored). 



Table 21.2: System Resource Health Monitoring Metrics 



Metric 


Units 


Threshold/Interval 

Defaults 


Notes 


CPU Utilization 


Percentage 


Critical: 95/120 
Warning: 80/120 


Measures the value of CPU 0 on 
multi-processor systems — not the 
average of all CPU activity. 


Memory Pressure 


Percentage 


Critical: 95/120 
Warning: 90/120 


Memory pressure occurs when 
memory resources become limited, 
causing new connections to be 
delayed. 


Network Utilization 


Percentage 


Critical: 90/120 
Warning: 60/120 


Measures the traffic (in and out) on 
the interface to determine if it is 
approaching the maximum allowable 
bandwidth. 


License Utilization 


Percentage 


Critical: 100/0 
Warning: 90/0 


For licenses that have user limits, 
monitors the number of users. 


License Expiration 


Days 


Critical: 0/0 
Warning: 30/0 


Warns of impending license 
expiration. 

For license expiration metrics, 
intervals are ignored. See "Monitoring 
Licensing Utilization and Expiration" 
on page 964for more information. 
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Monitoring Licensing Utilization and Expiration 

You can monitor the following licenses for utilization and / or expiration. 

Utilization / Expiration: 

□ AOL Instant Messaging (aol - im) 

□ MSN Instant Messaging (msn-im) 

□ Yahoo Instant Messaging (yahoo - im) 

□ Windows Media Streaming (windows -media) 

□ Real Media Streaming (real -media) 

□ Quicktime Streaming (quicktime) 

□ Expiration only: 

□ SGOS (sgos) 

Licenses not listed here are part of the SGOS base license. 

□ SSL (ssl) 

See "About License Expiration Metrics" on page 965for information licensing thresholds. 

About Health Monitoring Thresholds 

For the purposes of notification, thresholds are defined by two variables, the threshold level and the 
threshold interval: 

□ The threshold level describes the state of the metric: OK, Warning, or Critical. 

Note: Sensors have different threshold levels than OK, Warning, and Critical. See "About 

Hardware /Environmental Metrics (Sensors)" on page 962 for more information. 

□ The threshold interval specifies the period of time that the metric must stay in the level before an 
alert is triggered. 

For example, you might define the CPU utilization threshold levels as follows: 

□ Critical Level=95% 

□ Critical Threshold Interval=20 seconds 

□ Warning Level=85% 

□ Warning Threshold Interval=20 seconds 

A metric is not considered to have changed state unless it stays above a threshold level for the 
specified interval. Thus, the variables in the preceding example indicate that the metric is not 
considered Critical unless it stays at 95% or above for at least 20 seconds. If the CPU hovers between 
95% and 100% for 20 seconds, a Critical alert is sent. 
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Similarly, if the CPU stays between 85% and 94% for 20 seconds, a Warning alert is sent. Conversely, 
an alert notification is not sent if the CPU hovers in the Warning level for 18 seconds and then drops to 
normal. 

An alert is triggered if a metric stays above any threshold for the specified interval. For example, if the 
CPU rises above the Warning level for 9 seconds, climbs into the Critical level for 18 seconds, and then 
falls to 45%, a Warning notification is sent because the metric stayed above the Warning threshold for 
27 seconds. This concept is illustrated in the following figure. 




Figure 21-1 : Relationship between the threshold level and threshold interval 
About License Expiration Metrics 

The threshold values for license expiration metrics are set in days until expiration. In this context, a 
"critical" threshold indicates that license expiration is imminent. This is the only metric in which the 
Critical threshold value should be smaller than the Warning threshold value. For example, if you set 
the Warning threshold to 45, an alert is sent when there are 45 days remaining in the license period. 
The Critical threshold would be less than 45 days, for example 5 days. 

For the license expiration metrics, the threshold interval is irrelevant and is set by default to 0. You 
should set the Warning Threshold to a value that will give you ample time to renew your license. By 
default, all license expiration metrics have a Warning Threshold of 30 days. By default, the Critical 
Threshold is configured to 0, which means that a trap is immediately sent upon license expiration. 



Note: The license expiration OK state can have three possible threshold values: Not installed: 

state ok, threshold value -1; Installed Permanently: state ok, threshold value 0; N days 
remaining to expire: state ok, threshold value N. 
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About Health Monitoring Notification 

By default, the health monitoring metrics are configured to send an SNMP trap to the management 
station whenever a threshold change occurs. Other types of notification are also available. Any or all 
of the following types of notification can be set: 

□ SNMP trap 

Sends an SNMP trap to all configured management stations. 

□ E-mail 

Sends e-mail to all persons listed in the Event log properties. 

□ Log 

Inserts an entry into the Event log. See "Event Logging and Notification" on page 951 for more 
information. 

Changing Threshold and Notification Properties 

The health monitoring threshold and notification properties are set by default. Use the following 
procedure to modify the current settings. 

Note: Thresholds and notifications can also be set by editing the MIB (SNMP Sets). 

To change the threshold and notification properties: 

1. Select Maintenance > Health Monitoring. 

2. Do one of the following: 

• To change the system resource metrics, select General. 

• To change the hardware/environmental metrics, select Sensors. 

Note: You cannot change the threshold values for metrics in the Sensors tab. 

• To change the licensing metrics, select Licensing. 

3. Select the metric you want to modify. 

4. Click Edit to modify the threshold and notification settings. The Edit Metric dialog displays. (Sensor 
thresholds cannot be modified.) 
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5a 



6 



5. Modify the threshold values: 

c. To change the critical threshold, enter a new value in the Critical Threshold field. 

d. To change the critical interval, enter a new value in the Critical Interval field. 

e. To change the warning threshold, enter a new value in the Warning Threshold field. 

f. To change the warning interval, enter a new value in the Warning Interval field. 

6. Modify the notification settings. 

• Log adds an entry to the Event log. 

• Trap sends an SNMP trap to all configured management stations. 

• Email sends an e-mail to the addresses listed in the Event log properties. See "Event Logging 
and Notification" on page 951 for more information. 

7. Click OK to close the Edit Metric dialog. 

8. Click Apply. 

Related CLI Syntax to Modify Threshold and Notification Properties 

# (config) alert threshold metric_name warning_threshold warning_interval 
cri tical_ threshol d cri tical_int erval 

# (config) alert notification met ric_name notification_method 

Getting A Quick View of the ProxySG Health 

The Management Console uses the health monitoring metrics to display a visual representation of the 
overall health state of the ProxySG. The health icon is located in the upper right comer of the 
Management Console and is always visible. 
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System health is determined by calculating the "aggregate" health status of the following metrics: 

□ CPU Utilization 

□ Memory Pressure 

□ Network interface utilization 

□ Disk status (for all disks) 

□ License expiration 

□ License "user count" utilization (when applicable) 

□ Sensor values (for all sensors) 

The possible ProxySG health states are OK, Warning, or Critical. 

Clicking the health icon displays the Statistics>Health page, which lists the current condition of the 
system's health monitoring metrics, as described in the next section. 

Viewing Health Monitoring Statistics 

While the health icon presents a quick view of ProxySG health, the Statistics>Health page enables you 
to get more details about the current state of the health monitoring metrics. 

To review the health monitoring statistics: 

1. From the Management Console, select Statistics>Health. 



General | Licensing 

General 



Sensors 



Metric 

CPU utilization 



Value 
1 percent 



Memory pressure 



Disk 1 status 



Interface 0:0 utilization 



Interface 0:1 utilization 



82 percent 



0 percent 



0 percent 



State 

OK 



OK 



OK 



OK 



Set thresholds... 



View o- 



2. Select a health monitoring statistics tab: 



968 





Chapter 21 : Maintaining the ProxySG 



• General: Lists the current state of CPU utilization, interface utilization, memory pressure, and 
disk status metrics. 

• Licensing: Lists the current state of license utilization and expiration metrics. 

• Sensors: Lists the current state of all sensor metrics. 

3. To get more details about a metric, highlight the metric and click View. The View Metrics Detail 
dialog displays. 




4. Click Close to close the View Metrics Detail dialog. 

5. Optional — If you want to modify a metric, highlight the metric and click Set Thresholds. The 
Maintenance>Health Monitoring page displays. To modify the metric, follow the procedure describe 
in "Changing Threshold and Notification Properties" on page 966. 

Related CLI Syntax to View Health Monitoring Statistics 

SGOS# (config) show system-resource-metrics 
The show system-resource-metrics command lists the state of the current system resource metrics. 

Sensor notification varies by ProxySG platform. If you try to set notification for a sensor that does not 
support notification, you will see the following error message: 

Sensor not supported on this platform 

Depending on the ProxySG platform, the sensor metrics displayed by the show 
system-resource-metrics command might differ from the sensor names listed in the alert 
command output. For example, the bus-temperature sensor can be shown as motherboard 
temperature in the show system- resources -metrics output. If you are setting notification from the 
Management Console, you can verify the sensor category by clicking the Preview button to view the 
CLI output. 
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Troubleshooting 

If you continue to receive alerts, contact Blue Coat Technical Support. For licensing questions, contact 
Blue Coat Support Services. It is helpful to obtain a packet capture for CPU, memory pressure, and 
network interface issues, before calling Technical Support. 

Table 21.3: Technical Support and Support Services Contact Information 



Blue Coat Technical Support 


1. 866.36. BCO AT (Toll Free) 

http: / /www.bluecoat.com/support/index.html 

http: / /www.bluecoat.com/support/ contact.html 


Blue Coat Support Services 


http: / / www.bluecoat.com/ support/ services /index.html 



Disk Reinitialization 

You can reinitialize disks on a multi-disk ProxySG. You cannot reinitialize the disk on a single-disk 
ProxySG: If you suspect a disk fault in a single-disk ProxySG, contact Blue Coat. Technical Support for 
assistance. 



Note: If a disk containing an unmirrored event or access log is reinitialized, the logs are lost. 

Similarly, if two disks containing mirrored copies of the logs are reinitialized, both copies 
of the logs are lost. 



Multi-Disk ProxySG 

On a multi-disk ProxySG, the master disk is the leftmost valid disk. Valid means that the disk is online, 
has been properly initialized, and is not marked as invalid or unusable. 

If the current master disk is taken offline, reinitialized, or declared invalid or unusable, the leftmost 
valid disk that has not been reinitialized since restart becomes the master disk. Thus, as disks are 
reinitialized in sequence, a point is reached where no disk can be chosen as the master. At this point, 
the current master disk is the last disk. If this disk is taken offline, reinitialized, or declared invalid or 
unusable, the ProxySG is restarted. 

On a multi-disk ProxySG, a disk is reinitialized by setting it to empty and copying pre-boot programs, 
boot programs, and starter programs, and system images from the master disk to the reinitialized 
disk. 

Reinitialization is done online without rebooting the ProxySG. (For more information, refer to the 
#disk command in the Blue Coat ProxySG Command Line Reference.) ProxySG operations, in turn, are 
not affected, although during the time the disk is being reinitialized, that disk is not available for 
caching. Only the master disk reinitialization restarts the ProxySG. 

Only persistent objects are copied to a newly-reinitialized disk. This is usually not a problem because 
most of these objects are replicated or mirrored. If the reinitialized disk contained one copy of these 
objects (which is lost), another disk contains another copy. 
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You cannot reinitialize all of the ProxySG disks over a very short period of time. Attempting to 
reinitialize the last disk in a ProxySG before critical components can be replicated to other disks in the 
system causes a warning message to appear. 

Immediately after reinitialization is complete, the ProxySG automatically starts using the reinitialized 
disk for caching. 

Single-Disk ProxySG 

The disk on a single-disk ProxySG cannot be reinitialized by the customer. If you suspect a disk fault 
in a single-disk ProxySG, contact Blue Coat Technical Support for assistance. 

Deleting Objects from the ProxySG 

The ability to delete either individual or multiple objects from the ProxySG makes it easy to delete 
stale or unused data and make the best use of the storage in your system. 



Note: The maximum number of objects that can be stored in a ProxySG is affected by a number 

of factors, including the SGOS version it is running and the hardware platform series. 



This feature is not available in the Management Console. Use the CLI instead. 

To Delete a Single Object from the ProxySG through the CLI 

At the (config) prompt, enter the following command: 

SGOS# (config) content delete url url 

To Delete Multiple Objects from the ProxySG through the CLI 

At the (config) prompt, enter the following command: 

SGOS# (config) content delete regex regex 
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The Statistics tabs of the Management Console allows you to graphically view the status of many 
system operations, take disks offline, and put them online. Many statistics are available through the 
CLI, but without the benefit of graphical display. 

You can also view detailed system information through the CLI using the show command. Access this 
command through either the enable command prompt (sgos#) or the config command prompt 
(sgos# (config) ). For convenience, the procedures in this chapter show only the enable command 
prompt. 

Selecting the Graph Scale 

Some statistics are reported in the form of bar graphs. Most bar graphs offer the option to show all 
values in the graph or to clip a percentage of the peak values, which means that a percentage is 
allowed to fall off the scale. For example, if you select clip 25% of peaks, the top 25% of the values are 
allowed to exceed the scale for the graph, showing greater detail for the remaining 75% of the values. 
To set the graph scale, select a value from the Graph scale should drop-down list. Some of the graphs 
offer the option of viewing statistics in bytes or objects. On these pages, you can switch among 
viewing modes by selecting bytes served or objects served mode from the Graph shows or Percentages 
reflect drop-down list. 

You can also move your cursor over the bar graphs to dynamically display color-coded statistical 
information. See Figure 22-8 for an example of this. 



General Statistics 

The General statistics tabs in the Management Console (Summary, Environment, and Disks) provide 
information about system configuration and the status of hardware sensors and allow you to take 
disks offline and put them online. These statistics are also available in the CLI. 



Note: The ProxySG 400 Series Appliances do not have an Environment tab. 



System Summary 

The device provides a variety of information on its status. The fields on the Summary tab are 
described below: 

□ Disks Installed — the number of disk drives installed in the device. The Disks tab displays the status 
of each drive. 

□ Memory installed — the amount of RAM installed in the device. 

□ CPUs installed — the number of CPUs installed in the device. 

□ Software image — the version and release number of the device image. 
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□ Serial number — the serial number of the machine, if available. 

□ System started — the time and date the device was started. 

□ CPU utilization — the current percent utilization of the device CPU. 

Viewing the System Summary 

To View the System Summary Statistics through the Management Console 
Select Statistics>General>Summary. 



Summary j SSL Accelerators | Disk 

- Configuration 

Disks installed: 1 

Memory installed: 128 megabytes 
CPUs installed: 1 

Software image: SGOS 4.2. 1.1, Release id: 25367 Debug 

Serial number: (not available) 



- General Status 

System started : 2006-03-28 18:43: 00+00 : 00UTC 
CPU utilization: 2 percent 



Figure 22-1 : General Summary Tab 



Help 



To View the System Summary through the CLI 



Enter the following command at the prompt: 



SGOS# show status 

Conf igurat ion : 

Disks installed: 
Memory installed: 
CPUs installed: 
Software version: 
Release id: 
Machine id: 

Serial number: 

NIC 0 MAC: 

General status : 
System started: 
CPU utilization: 



2 

768 megabytes 
1 

SG 4 . 1 
21574 

0 0D0B7 655D4 8 
(not available) 

0 0D0B7 655D0 1 

2004-09-10 18 : 05 : 14+00 : 00UTC 
17% 
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Viewing SSL Accelerator Cards 

Selecting the Statistics>General>SSL Accelerator tab allows you to view information about any SSL 
accelerator cards in the system. If no accelerator cards are installed, that information is stated on the 
pane. 

To View SSL Accelerator Cards through the Management Console 



Note: You cannot view statistics about SSL accelerator cards through the CLI. 



Select Statistics>General>SSL Accelerator. 



Summary SSL Accelerators | Environment | 



Disks 1-8 



- SSL Accelerators 

Broadcom BCM5825: 1 



Help 

Figure 22-2: View SSL Accelerator Card Statistics 

Viewing System Environment Sensors 

The icons on the Environment tab are green when the related hardware environment is within 
acceptable parameters, and red when an out-of-tolerance condition exists. If an icon is red, click View 
Sensors to view detailed sensor statistics to learn more about the out-of-tolerance condition. 



Note: You cannot view environment statistics on a ProxySG 400 Series Appliance. 



To View the System Environment Statistics through the Management Console 
1. Select Statistics>General>Environment. 



Note: This tab varies depending on the type of ProxySG that you are using. 
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Summary Environment | Disks 1-2 

- T emperature 

o 



View Sensors 

Help 

Figure 22-3: Environment Tab 

2. Click View Sensors to see detailed sensor values; close the window when you are finished. 

Sensor statistics 



Sensor Name Reading 


Status 


MB Temperature |31.0 C 


OK 


CPU Temperature 31.0 C 


OK 



Figure 22-4: Sensor Statistics Window 
To View the System Environmental Statistics through the CLI 

Note: You cannot view environmental statistics on a ProxySG 400 Series Appliance. 



Enter the following command at the prompt (the results that display vary among ProxySG platforms): 

SGOS# show environmental 

Environmental Sensor Information 
Baseboard Temperature # 1 : 

Temperature Reading: 27.0 C 

Current Threshold Status : NOMINAL -- OK 



% 


UPPER 


CRITICAL 


: 60.0 


% 


UPPER 


NON CRITICAL 


: 55.0 


% 


LOWER 


NON CRITICAL 


: 0.0 


% 


LOWER 


CRITICAL 


I- 1 

o 

o 



Baseboard Temperature # 2 : 

Temperature Reading: 25.0 C 

Current Threshold Status : NOMINAL -- OK 
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% UPPER 


CRITICAL : 


60 . 0 


% UPPER 


NON CRITICAL : 


55 . 0 


% LOWER 


NON CRITICAL : 


0 . 0 


% LOWER 


CRITICAL : 


-10.0 


Baseboard Voltage # : 1 




Voltage 


Reading : 1.4 




Current 


Threshold Status 


: NOMINAL 


% UPPER 


CRITICAL : 


1 . 7 


% LOWER 


CRITICAL : 


1.2 


Fans 


Fan #1 


Running OK 




Fan #2 


Running OK 





Power Supplies 
Power Supply #1 : OK 
Power Supply #2 : OK 

where the Upper (non) Critical and Lower (non) Critical Temperature and Voltage 
values are for reference and indicate values that are (critically or non-critically) too high or too 
low. The Temperature/Voltage Reading indicates the current status of the ProxySG. The 
Current Threshold Status indicates whether a problem exists. 

Viewing Disk Status 

You can view the status of each of the disks in the system and take a disk offline if needed. 

To View Disk Status or Take A Disk Offline through the Management Console 
1. Select Statistics>General>Disks. 

The default view provides information about the disk in slot 1 . 



Note: The name and appearance of this tab differs, depending on the range of disks available to 

the ProxySG model you use. 
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Summary 
- Disk in slot 1 


Disk 












Vendor: 


SAMSUNG 


Product: 


SAMSUNG SV0431D 


Revision: 


MA10 


Disk SN: 


0162J1CN1 11005 


Capacity: 


4.31 gigabytes 


Status: 


PRESENT 



Help 

Figure 22-5: Disks Tab 

2. Select the disk to view or to take offline by clicking the appropriate disk icon. 

3. (Optional) To take the selected disk offline, click the Take disk x offline button (where x is the 
number of the disk you have selected); click OK in the Take disk offline dialog that displays. 



3 Take disk offline 



Confirmation required 

ARE YOU SURE YOU WANT TO TAKE THE DISK OFFLINE? 
This action may result in data loss! 

Press "OK" to take the disk offline. 



OK | Cancel | 

Figure 22-6: Take Disk Offline Dialog 

To View Disk Statistics through the CLI 

Enter the following command at the prompt: 

SGOS# show disk {all | disk_number } 

where all displays information about all disks and disk_number displays information about 
the disk specified. 

To Take a Disk Offline through the CLI 

Enter the following command at the prompt: 

SGOS# disk offline disk_number 

where disk_number is the number of the disk that you want to take offline. 
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System Usage Statistics 

The System Usage tabs (CPU, Bandwidth Gain, Client Comp. Gain, Server Comp. Gain, Freshness, 
and Refresh Bandwidth) display bar graphs that illustrate the last 60 minutes, 24 hours, and 30 days 
for CPU utilization, bandwidth gain, client and server compression gain, freshness of objects in the 
cache, and the average network bandwidth used to maintain freshness. 

Viewing CPU Utilization 

Through the Management Console, you can view the average CPU utilization percentages for the 
ProxySG over the last 60 minutes, 24 hours, and 30 days. You can see the current CPU utilization 
statistic through the CLI. 

To View CPU Utilization through the Management Console 
1. Select Statistics>System Usage>CPU. 




Figure 22-7: CPU Tab 

2. (Optional) To set the graph scale to clip a percentage of the peaks in value, select a percentage 
from the Graph scale should drop-down list. 

To View CPU Utilization through the CLI 

Enter the following command at the prompt: 

SGOS# show cpu 

Viewing Bandwidth Gain 

Through the Management Console, you can view bandwidth-gain statistics for the ProxySG over the 
last 60 minutes, 24 hours, and 30 days. These statistics are not available through the CLI. 

The green display on the bar graph represents client data; the blue display represents server data. 
Hover your cursor over the graph to see the bandwidth gain data. 
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It is normal to see 100% markers in places where there has been no client-use for the activity. This 
means that, of the server-side traffic being expended, 100% of it is being expended for ProxySG 
internal usage, such as asynchronous adaptive refresh. 

To View Bandwidth Gain Statistics through the Management Console 
1. Select Statistics>System Usage>Bandwidth Gain. 



CPU Bandwidth Gain Freshness | Refresh Bandwidth 




clip 50% of peaks 



|clip 75% of peaks | 

Figure 22-8: Bandwidth Gain Tab 

2. (Optional) To set the graph scale to a different value, select a value from the Graph scale should 
drop-down list. 

Viewing Cache Freshness 

The Freshness tab illustrates the estimated freshness of objects in the cache over the last 60 minutes, 24 
hours, and 30 days. These statistics are not available through the CLI. 

Freshness applies only to objects that are cached (all objects that are not cached are always 100% 
fresh). For example, if the estimated freshness is 99%, that means when you request an object there is a 
99% chance that object is fresh in the cache. 

To View Cache Freshness through the Management Console 
1. Select Statistics>System Usage>Freshness. 



980 




Chapter 22: Statistics 



CPU | Bandwidth Gain 

Previous SO minute period 



Freshness 



Refresh Bandwidth 



milllHIII IIIIIIIIIIIIIIIIIIIIIIIITT 


llllllllllllllllllll 


1111111111111111111111111111111111111 

lllllllllll■lllllllllllllllllllllllll 





60 



45 



30 



100% 



15 




Graph scale should: [ show all values v |( Help 

Figure 22-9: Freshness Tab 



2. (Optional) To set the graph scale to a different value, select a value from the Graph scale should 
drop-down list. 



Viewing Refresh Bandwidth Statistics 

The Refresh Bandwidth tab illustrates the average network bandwidth used to maintain freshness in 
the cache over the last 60 minutes, 24 hours, and 30 days. These statistics are not available through the 
CLI. 

To View Refresh Bandwidth through the Management Console 
1. Select Statistics>System Usage>Refresh Bandwidth. 
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CPU | Bandwidth Gain | Freshness Refresh Bandwidth 

- Previous 60 minute period 



















60 45 30 1 


0 



0 































0 


24 


18 12 6 0 






























0 


28 21 14 


7 0 



Graph scale should: show all values v [ Help 

Figure 22-10: Refresh Bandwidth Tab 



2. (Optional) To set the graph scale to a different value, select a value from the Graph scale should 
drop-down list. 



HTTP/FTP History Statistics 

The HTTP/FTP History tabs (HTTP /HTTPS /FTP Objects, HTTP /HTTPS /FTP Bytes, HTTP/HTTPS 
/FTP Clients, Client Comp. Gain, and Server Comp. Gain) display bar graphs that illustrate the last 60 
minutes, 24 hours, and 30 days for the number of HTTP /HTTPS /FTP objects served, the number of 
HTTP /HTTPS /FTP bytes served, the maximum number of active HTTP /HTTPS /FTP clients 
processed, and the HTTP/FTP client and server compression-gain statistics. Overall client and server 
compression-gain statistics are displayed under System Usage. 



Note: You can view current HTTP configurations and statistics through the CLI using the show 

http and show http- stats commands. 



Viewing the Number of HTTP/FTP Objects Served 

The HTTP /HTTPS /FTP Objects tab illustrates the device activity over the last 60 minutes, 24 hours, 
and 30 days. These charts illustrate the total number of objects served from either the cache or from 
the Web. To review the number of cached objects versus non-cached objects, view the Efficiency tabs. 



Note: The maximum number of objects that can be stored in a ProxySG is affected by a number 

of factors, including the SGOS version it is running and the hardware platform series. 



To View the Number of HTTP7HTTPS/FTP Objects Served through the Management Console 
1. Select Statistics>HTTP/FTP History>HTTP/HTTPS/FTP Objects. 
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HTTP/HTTPS/FTP Objects 

r Previous 60 minute period 



60 



45 



Previous 24 hour period 



Previous 30 day period 



28 



21 



HTTP/HTTPS/FTP Bytes 



30 



14 



15 



Graph scale should: j show all values v f" 

Figure 22-1 1 : HTTP/HTTPS/FTP Objects Tab 



HTTP/HTTPS/FTP ClN I ► 



n/a 



n/a 



n/a 



Help 



2. (Optional) To set the graph scale to a different value, select a value from the Graph scale should 
drop-down list. 



Viewing the Number of HTTP/HTTPS/FTP Bytes Served 

The Bytes tab shows the sum total of the number of bytes served from the device over the last 60 
minutes, 24 hours, and 30 days. The chart shows the total number of bytes for objects served by the 
device, including both cache hits and cache misses. 

To View the Number of HTTP/HTTPS/FTP Bytes Served through the Management Console 
1. Select Statistics>HTTP/FTP History>HTTP/HTTPS/FTP Bytes. 



HTTP/HTTPS/FTP Objects HTTP/HTTPS/FTP Bytes | HTTP/HTTPS/FTP Cl( « | ► 

Previous 60 minute period 




Graph scale should: show all values 

Figure 22-12: HTTP/FTP Bytes Tab 



983 



Blue Coat Proxy SG Configuration and Management Guide 



2. (Optional) To set the graph scale to a different value, select a value from the Graph scale should 
drop-down list. 

Viewing Active Client Connections 

The HTTP /HTTPS /FTP Clients tab shows the maximum number of clients with requests processed 
over the last 60 minutes, 24 hours, and 30 days. This does not include idle client connections 
(connections that are open but that have not made a request). These charts allow you to monitor the 
maximum number of active clients accessing the ProxySG at any one time. In conjunction with the 
HTTP /HTTPS /FTP Objects and HTTP /HTTPS /FTP Bytes tabs, you can determine the number of 
clients supported based on load, or load requirements for your site based on a specific number of 
clients. 

To View the Number of Active Clients through the Management Console 
1. Select Statistics>HTTP/FTP History>HTTP/HTTPS/FTP Clients. 




Figure 22-1 3: HTTP/HTTPS/FTP Clients Tab 



2. (Optional) To set the graph scale to a different value, select a value from the Graph scale should 
drop-down list. 

Viewing HTTP/FTP Client and Server Compression Gain Statistics 

Under HTTP /FTP History, you can view HTTP /FTP client and server compression-gain statistics for 
the ProxySG over the last 60 minutes, 24 hours, and 30 days in the Client Comp. Gain and the Server 
Comp. Gain tabs. Overall client and server compression-gain statistics are displayed under System 
Usage. These statistics are not available through the CLI. 

The green display on the bar graph represents uncompressed data; the blue display represents 
compressed data. Hover your cursor over the graph to see the compressed gain data. 
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To View HTTP/FTP Client Compressed Gain Statistics through the Management Console 
1. Select Statistics> HTTP/FTP History>Client Comp. Gain. 




2. (Optional) To set the graph scale to a different value, select a value from the Graph scale should 
drop-down list. 

To View HTTP/FTP Server Compressed Gain Statistics through the Management Console 
1. Select Statistics>HTTP/FTP History>Server Comp. Gain. 



HTTP/HTTPS/FTP Clients | Client Comp. Gain Server Comp. Gain < | > 




Graph scale should: | show all values v i( Help 

Figure 22-15: HTTP/FTP Server Comp. Gain Tab 

2. (Optional) To set the graph scale to a different value, select a value from the Graph scale should 
drop-down list. 
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IM History Statistics 

The IM statistics allow you to track IM connections, file transfers, and messages that are currently in 
use and in total, or have been allowed and denied. The information can be displayed for each IM 
client type or combined. 



IM Connection Data Tab 

The following IM Connection Data statistics indicate current and overall connection data since the last 
statistics clear: 

□ Native Clients — The number of native IM clients connected. 

□ HTTP Clients — The number of HTTP IM clients connected. 

□ Chat Sessions — The number of IM chats occurring. 

□ Direct IM Sessions — The number of chats using direct connections. 

□ File Transfers — The number of file transfers sent through IM clients. 

To View the Connection Data Statistics through the Management Console 
1. Select Statistics>IM History>IM Connection Data. 



IM Connection Data 

IM Statistics 



IM Activity Data 



IM Clients 



Protocol: 



Native Clients: 
HTTP Clients: 

Chat Sessions: 
Direct IM Sessions: 
File Transfers: 



All 



Current 

0 

0 

0 

0 

0 



Total 

0 

0 

0 

0 

0 



□ 

Figure 22-16: IM Connection Statistics Data Tab 



Help 



2. The default protocol is All. To select a specific protocol, select AOL, MSN, or Yahoo from the 
drop-down list. 



IM Activity Data Tab 

The following IM Activity Data statistics indicate allowed and denied connections since the last 
statistics clear: 

□ Logins — The number of times IM clients have logged in. 
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□ Messages — The number of IM messages. 

□ File Transfers — The number of file transfers sent through IM clients. 

□ Voice Chats — The number of voice conversations through IM clients. 

□ Messages — The number of IM messages reflected or not reflected (if IM Reflection policy is 
enabled). 

Note: The IM activity data statistics are available only through the Management Console. 



To View the Activity Data Statistics through the Management Console 
1. Select Statistics>IM History>IM Activity Data. 



IM Connection Data 



IM Activity Data | IM Clients 



ii'i Jiauz'i-n.-j 



Logins: 

Messages: 

File Transfers: 
Voice Chats: 

Messages: 



Protocol: 



All 



v 



Allowed 

0 

0 

0 

0 

Reflected: 



0 



Denied 

0 

0 

0 

0 

Not Reflected: 



0 



[ Help J 

Figure 22-17: IM Activity Statistics Data Tab 

2. The default protocol is All. To select a specific protocol, select AOL, MSN, or Yahoo from the 
drop-down list. 



IM Clients Tab 

The IM Clients tab displays dynamic graphical statistics for connections over 60 minutes, 24 hours and 
30 days. The page displays all values in the graph or clip a percentage of peak values. When peak 
values are clipped by a percentage, that percentage is allowed to fall off the top of the scale. 

For example, if you clip 25% of the peaks, the top 25% of the values are allowed to exceed the scale for 
the graph, showing greater detail for the remaining 75% of the values. 

Move the cursor over the graphs to dynamically display the color-coded AOL, MSN, Yahoo, and total 
statistics. 



Note: The IM clients statistics are available only through the Management Console. 
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To View the Client Connection Statistics through the Management Console 
1. Select Statistics>IM History>IM Clients. 




Figure 22-18: IM Client Data Statistics 



2. (Optional) To set the graph scale to a different value, select a value from the Graph scale should 
drop-down list. 

IM Statistics and Configuration in the CLI 

To View IM Statistics through the CLI 

Enter the following command at the prompt: 

SGOS# show im {aol-statistics | msn- statistics | yahoo- statistics } 

To View the IM Configuration through the CLI 

Enter the following command at the prompt: 

SGOS# show im configuration 

P2P History Statistics 

You can construct policy that controls, blocks, and logs peer-to-peer (P2P) activity and limits the 
bandwidth consumed by P2P traffic (see "Section E: Managing Peer-to-Peer Services" on page 725 for 
information about constructing P2P policy). The following section explains how to view P2P statistics, 
using either the Management Console or the CLI. 



Note: Some P2P statistics (P2P client connections and total bytes sent and received over a period 

of time) can only be viewed through the Management Console (see "P2P Clients" and 
"P2P Bytes", below). 
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P2P Data 

The P2P Data tab on the Management Console displays P2P statistics, either all P2P services at once or 
one service at a time. 

Table 22.1 details the statistics provided through the Management Console P2P Data tab or through 
the CLI. 

Table 22.1 : P2P Data Statistics 



Status 


Description 


Current Tunneled Sessions 


The current number of P2P client connections using native 
transport. 


Current HTTP Requests 


The current number of HTTP requests from P2P clients. 


Total Tunneled Sessions 


The cumulative number of P2P client connections using native 
transport since the ProxySG was last rebooted. 


Total HTTP Requests 


The cumulative number of HTTP requests from P2P clients 
since the ProxySG was last rebooted. 


Total Bytes Received 


The total number of bytes received from all P2P clients. 


Total Bytes Sent 


The total number of bytes sent to all P2P clients. 



To View P2P Data Statistics through the Management Console 
1. Select Statistics>P2P History>P2P Data. 

The default view shows all P2P protocols. 



P2P Data P2P Clients 

P2P Statistics 



P2P Bytes 



Protocol: 



All 



Current Tunneled Sessions: 
Current HTTP Requests: 
Total Tunneled Sessions: 
Total HTTP Requests: 

Total Bytes Received: 

Total Bytes Sent: 



Figure 22-1 9: P2P Data Tab 



r 



Help 



2. (Optional) To view the statistics for a specific P2P protocol, make a selection from the Protocol 
drop-down list. 
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To View P2P Data Statistics through the CLI 

Enter the following command at the prompt: 

SGOS# show p2p statistics 

P2P Clients 

You can view the total number of P2P client connections received in the last 60 minute, 24 hour, or 30 
day period. 



Note: The P2P client statistics are available only through the Management Console. 



To View P2P Client Statistics through the Management Console 
1. Select Statistics>P2P History>P2P Clients. 
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Figure 22-20: P2P Clients Tab 

2. (Optional) To set the graph scale to a different value, select a value from the Graph scale should 
drop-down list. 

P2P Bytes 

You can view the total number of bytes sent to and received from P2P clients in the last 60 minute, 24 
hour, or 30 day period. 



Note: The P2P bytes statistics are available only through the Management Console. 



To View P2P Byte Statistics through the Management Console 
1. Select Statistics>P2P History>P2P Bytes. 
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Figure 22-21 : P2P Bytes Tab 

2. (Optional) To set the graph scale to a different value, select a value from the Graph scale should 
drop-down list. 

SSL History Statistics 

The SSL History tabs (Unintercepted SSL Data, Unintercepted SSL Clients, Unintercepted SSL Bytes) 
provide various useful statistics for unintercepted SSL traffic. 



Note: Some SSL statistics (SSL client connections and total bytes sent and received over a period 

of time) can only be viewed through the Management Console (see "Unintercepted SSL 
Data" and "Unintercepted SSL Clients", below). 



Unintercepted SSL Data 

The Unintercepted SSL Data tab on the Management Console displays SSL statistics. 

Table 22.2 details the statistics provided through the Management Console Unintercepted SSL Data 
tab. 

Table 22.2: Unintercepted SSL Data Statistics 



Status 


Description 


Current Unintercepted SSL Sessions 


The current number of unintercepted SSL client connections. 


Total Unintercepted SSL Sessions 


The cumulative number of unintercepted SSL client 
connections since the ProxySG was last rebooted. 


Total Bytes Sent 


The total number of unintercepted bytes sent. 


Total Bytes Received 


The total number of unintercepted bytes received. 
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To View Unintercepted SSL Data Statistics through the Management Console 
Select Statistics>SSL History>Unintercepted SSL Data. 

The default view shows all unintercepted SSL data. 



Unintercepted SSL Data J Unintercepted SSL Clients | Unintercepted SSL f < | r 



r Unintercepted SSL Data 



Current Unintercepted SSL Connections: 
Total Unintercepted SSL Connections: 
Total Bytes Sent: 

Total Bytes Received: 



0 



0 

0 



0 



Help 



Figure 22-22: Unintercepted SSL Data Tab 

Unintercepted SSL Clients 

You can view the total number of unintercepted SSL client connections received in the last 60-minute, 
24-hour, or 30-day period. 

To View SSL Client Unintercepted Statistics through the Management Console 
1. Select Statistics>SSL History>Unintercepted SSL Clients. 
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Unintercepted SSL Data Unintercepted SSL Clients Unintercepted SSL Bytes 
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Figure 22-23: Unintercepted SSL Clients Tab 
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2. (Optional) To set the graph scale to a different value, select a value from the Graph scale should 
drop-down list. 



Unintercepted SSL Bytes 

You can view the total number of bytes sent to and received in the last 60 minute, 24 hour, or 30 day 
period. 

To View Unintercepted SSL Byte Statistics through the Management Console 
1. Select Statistics>SSL History>Unintercepted SSL Bytes. 



:ercepted SSL Data | Unintercepted SSL Clients Unintercepted SSL Bytes < | > 

T Previous 60 minute period 

n/a 



60 



45 



30 



r Previous 24 hour period 



n/a 



r Previous 30 day period 



28 



21 



Graph scale should: show all values 

Figure 22-24: Unintercepted SSL Bytes Tab 
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Help 
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2. (Optional) To set the graph scale to a different value, select a value from the Graph scale should 
drop-down list. 

Streaming History Statistics 

The Streaming History tabs (Windows Media, Real Media, and QuickTime) display bar graphs that 
illustrate the number of active client connections over the last 60 minutes, 24 hours, and 30 days. 
These statistics are not available through the CLI. The Current Streaming Data and Total Streaming 
Data tabs display real-time values for current connection and live traffic activity on the ProxySG. 
Current and total streaming data statistics are available through the CLI. 

Viewing Windows Media Statistics 

The Windows Media tab shows the number of active Windows Media client connections over the last 
60 minutes, 24 hours, and 30 days. 

To View Windows Media Client Statistics through the Management Console 
1. Select Statistics>Streaming History>Windows Media. 
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Figure 22-25: Windows Media Tab 
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2. (Optional) To set the graph scale to a different value, select a value from the Graph scale should 
drop-down list. 



Viewing Real Media Statistics 

The Real Media tab shows the number of active Real Media client connections over the last 60 
minutes, 24 hours, and 30 days. 
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To View Real Media Data Statistics through the Management Console 
1. Select Statistics>Streaming History>Real Media. 
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Figure 22-26: Real Media Tab 



2. (Optional) To set the graph scale to a different value, select a value from the Graph scale should 
drop-down list. 



Viewing QuickTime Statistics 

The QuickTime tab shows the number of active QuickTime client connections over the last 60 minutes, 
24 hours and 30 days. 

To View QuickTime Data Statistics through the Management Console 
1. Select Statistics>Streaming History>QuickTime. 
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Figure 22-27: QuickTime Tab 
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2. (Optional) To set the graph scale to a different value, select a value from the Graph scale should 
drop-down list. 



Viewing Current and Total Streaming Data Statistics 

The Management Console Current Streaming Data tab and the Total Streaming Data tab show 
real-time values for Windows Media, Real Media, and QuickTime activity on the ProxySG. These 
statistics can also viewed through the CLI. 

To View Current Streaming Data Statistics through the Management Console 
1. Select Statistics>Streaming History>Current Streaming Data. 
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Figure 22-28: Current Streaming Data Tab 



Help 
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2. Select a streaming protocol from the Protocol drop-down list. 

3. Select a traffic connection type (Live, On-Demand, or Pass-thru) from the drop-down list. 

To View Total Streaming Data Statistics through the Management Console 

1. Select Statistics>Streaming History>Total Streaming Data. 
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Figure 22-29: Total Streaming Data Tab 



2. Select a streaming protocol from the Protocol drop-down list. 

3. Select a traffic connection type (Live, On-Demand, or Passthru) from the drop-down list. 



To View Current and Total Streaming Data Statistics through the CLI 

Enter the following command at the prompt: 

SGOS# show streaming {quicktime | real-media | windows -media} statistics 



To Clear Streaming Statistics through the CLI 

Enter the following command at the prompt: 

SGOS# clear-statistics {quicktime | real-media | windows -media} 



SOCKS History Statistics 

The SOCKS History tabs (SOCKS Clients, SOCKS Connections, and SOCKS client and server 
compression) display client data. Connect, Bind, and UPD Associate requests, client and server UDP, 
TCP and compression requests. 



Note: The SOCKS history statistics are available only through the Management Console. 
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Viewing SOCKS Clients 

The SOCKS Clients tab displays SOCKS Client data. 

To View Socks Client Data 

Select Statistics>SOCKS History>SOCKS Clients. 
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Figure 22-30: SOCKS Client Tab 



Help 



Viewing SOCKS Connections 

The SOCKS Connections tab displays SOCKS Connection data. 

To View SOCKS Connection Data through the Management Console 
Select Statistics>SOCKS History>SOCKS Connections. 
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Figure 22-31 : SOCKS Connections Tab 



Help 



Viewing SOCKS Client and Server Compression Gain Statistics 

Under SOCKS History, you can view SOCKS client and server compression-gain statistics for the 
ProxySG over the last 60 minutes, 24 hours, and 30 days in the Client Comp. Gain and the Server 
Comp. Gain tabs. These statistics are not available through the CLI. 

The green display on the bar graph represents uncompressed data; the blue display represents 
compressed data. Hover your cursor over the graph to see the compressed gain data. 

To View SOCKS Client Compressed Gain Statistics through the Management Console 
1. Select Statistics>SOCKS History>Client Comp. Gain. 
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Figure 22-32: SOCKS Client Comp. Gain Tab 

2. (Optional) To set the graph scale to a different value, select a value from the Graph scale should 
drop-down list. 

To View SOCKS Server Compressed Gain Statistics through the Management Console 
1. Select Statistics>SOCKS History>Server Comp. Gain. 
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Figure 22-33: SOCKS Server Comp. Gain Tab 
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2. (Optional) To set the graph scale to a different value, select a value from the Graph scale should 
drop-down list. 
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Shell History Statistics 

The Shell History tab displays client connections on a per hour, per day, and per month basis. 



Note: The Shell history statistics are available only through the Management Console. 



To View Shell History Statistics through the Management Console 
1. Select Statistics>Shell History. 




Figure 22-34: Shell Clients History Tab 



2. (Optional) To set the graph scale to a different value, select a value from the Graph scale should 
drop-down list. 

Resources Statistics 

The Resources tabs (Disk Use, Memory Use, and Data) allow you to view information about how disk 
space and memory are being used, and how disk and memory space are allocated for cache data. You 
can view data allocation statistics through both the Management Console and the CLI, but disk and 
memory use statistics are available only through the Management Console. 

Viewing Disk Use Statistics 

The Disk Use tab shows the ProxySG disk usage. The fields on the tab are: 

□ System Objects — the percentage of storage resources currently used for non-access-log system 
objects. 

□ Access log — the percentage of storage resources currently used for the access log. 

□ Cache in Use — the percentage of non-system, non-access-log resources currently in use for cached 
objects. 
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□ Cache available — the percentage of non-system, non-access-log resources still available for caching 
objects. 

To View Disk Use Statistics through the Management Console 
Select Statistics>Resources>Disk Use. 



Disk Use | Memory Use | Data 




Figure 22-35: Disk Use Tab 



Viewing Memory Use Statistics 

The Memory Use tab shows the amount of memory used for RAM, the ProxySG itself, and for 
network buffers. The fields on the Memory Use tab are: 

□ RAM Cache — the amount of RAM that is used for caching. 

□ System allocation — the amount of RAM allocated for the device system. 

□ Network buffers — the amount of RAM currently allocated for network buffers. 

To View Memory Use Statistics through the Management Console 
Select Statistics>Resources>Memory Use. 
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Disk Use Memory Use Data 




Figure 22-36: Memory Use Tab 



Help 



Viewing Data Allocation Statistics in RAM and on Disk 

The Data tab shows the total and available disk space and RAM, and how they are currently allocated. 
The fields on the Data tab are described below. This information can also be viewed through the CLI. 

□ Maximum objects supported — the maximum number of objects that can be supported. 

□ Cached objects — the number of objects that are currently cached. 

□ Disk used by system objects — the amount of disk space used by the system objects. 

□ Disk used by access log — the amount of disk space used for access logs. 

□ Total disk installed — the total amount of disk space installed on the device. 

□ RAM used by cache — the amount of RAM allocated for caching. 

□ RAM used by system — the amount of RAM allocated for system use. 

□ RAM used by network — the amount of RAM allocated for network use. 

□ Total RAM installed — the total amount of RAM installed. 

To View Data Allocation Statistics through the Management Console 
Select Statistics>Resources>Data. 
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Disk Use | Memory Use Data 
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T otal RAM installed: 
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Help 

Figure 22-37: Resources Data Tab 

To View Data Allocation Statistics through the CLI 

Enter the following command at the prompt: 

SGOS# show resources 

Efficiency Statistics 

The Efficiency tabs (Summary, Non-cacheable, Access Pattern, and Data) allow you to see information 
about the flow of both cacheable and non-cacheable data through the ProxySG. You can also see 
information about how data is being served (such as, RAM, disk, origin). 

Viewing the Cache Efficiency Summary 

The Summary tab shows the percent of objects served from cache, the percent loaded from the 
network, and the percent that were non-cacheable. The data dates from the last device reset. The 
values shown are either objects served or bytes served, based on the Values reflect field at the bottom 
of the tab. The fields on the Summary tab are: 

□ Served from cache — the percentage of requests the device was able to serve from the cache. 

□ Loaded from source — the percentage of requests the device had to retrieve from the Web and was 
able to store in the cache. 

□ Non-cacheable — the percentage of requests for non-cacheable objects. 

To View the Cache Efficiency Summary 
1. Select Statistics>Efficiency>Summary. 
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Summary | Non-cacheable j Access Pattern | Data 




Percentages reflect: | obiects served v j Help 

Figure 22-38: Efficiency Summary Tab 

2. (Optional) To switch the view between objects served and bytes served, select either bytes served or 
objects served from the Graph shows drop-down list. 



Viewing a Breakdown of Non-Cacheable Data 

The Non-cacheable tab shows a breakdown of non-cacheable objects. It shows how many of the 
various types of non-cacheable requests have been handled. The non-cacheable request types are: 

□ Pragma no-cache — requests that specify non-cached objects, such as when a user clicks the refresh 
button in the Web browser. 

□ Password provided — requests that include a client password. 

□ Data in request — requests that include additional client data. 

□ Not a GET request — only the HTTP method GET request can be cached. These are all other methods 
(PUT, HEAD, POST, DELETE, LINK, and UNLINK). 

□ Cookie in response — responses that include an HTTP cookie. 

□ Password required — responses that require a client password. 

□ Negative response — failed responses, such as when a server or object is not available. This value is 
zero if the Cache Negative Responses option is enabled. 

□ Client unique CGI responses — unique responses generated by a CGI application for a specific client. 

To View a Breakdown of Non-Cacheable Data 
Select Statistics>Efficiency>Non-cacheable. 
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Summary Non cacheable | Access Pattern | Data 



Pragma no-cache: 0.7% 

Password provided: 0% 
Data in request: 0 % 

Not a GET request: <0.1% 
Cookie in response: <0.1 % 
Password required: 0% 

N egative response: 99. 1 % 
Client unique CGI: <0.1% 




% = objects served 



Help 



Figure 22-39: Non-Cacheable Tab 



Viewing the Cache Data Access Pattern 

The Access Pattern tab shows the number of cached requests served from RAM and disk. Cached 
objects are stored first in RAM. As time passes without additional requests for an object, the object is 
migrated to disk. 

To View the Cache Data Access Pattern 
Select Statistics>Efficiency>Access Pattern. 



Summary | Non-cacheable Access Pattern | Data 




X - bytes served [ Help 

Figure 22-40: Access Pattern Tab 
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Viewing Totals for Bytes Served 

The Data tab lists a breakdown of all requests served. The fields are: 

□ Served from cache — the number of objects served from the cache. 

□ Loaded from source — the number of objects that could not be served from the cache and were 
retrieved from the Web. 

□ Non-cacheable — the number of objects served that could not be cached. 

□ Pragma no-cache — requests that specify non-cached objects, such as when a user clicks the refresh 
button in a Web browser. 

□ Password provided — requests that include a client password. 

□ Data in Request — requests that include additional client data. 

□ Not a GET request — requests that include an invalid HTTP method. 

□ Cookie in response — responses that include an HTTP cookie. 

□ Password required — responses that require a client password. 

□ Negative response — failed responses, such as when a server or object is not available. This 
information is only displayed if the Cache Negative Responses option is disabled. 

□ Client unique CGI — responses that contain unique CGI data. 

□ Accessed from RAM — the total number of bytes served from the RAM cache. 

□ Accessed from disk — the total number of bytes served from the disk cache. 

To View Totals For Bytes Served 

1. Select Statistics>Efficiency>Data. 



Summary 



Non-cacheable 



Access Pattern 



Data 



Served from cache: 289.1 9 kilobytes 68 objects 

Loaded from source: 1.59 megabytes 234 objects 

Non-cacheable: 3.18 megabytes 32,376 objects 



Pragma no-cache: 258 
Password provided: 0 
Data in request: 0 

Not a GET request: 9 



Cookie in response: 3 
Password required: 0 
N egative response: 32,1 05 
Client unique CGI: 1 



Accessed from RAM: 33.44 megabytes 
Accessed from Disk: 2.2 megabytes 



Clear statistics 



Help 



Figure 22-41 : Efficiency Data Tab 
2. (Optional) To clear all statistics, click Clear statistics. 
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Contents Statistics 

The Contents tabs (Distribution and Data) allow you to see information about objects currently stored 
or served organized by size. The cache contents include all objects currently stored by the ProxySG. 
The cache contents are not cleared when the ProxySG is powered off. 

Viewing Cached Objects by Size 

The Distribution tab shows the objects currently stored by the ProxySG, ordered by size. 

To View the Distribution of Cache Contents 
Select Statistics>Contents>Distribution. 
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Figure 22-42: Contents Distribution Tab 



Viewing the Number of Objects Served by Size 

The Data tab displays the number of objects served by the ProxySG, organized by size. This chart 
shows you how many objects of various sizes have been served. 

To View the Number of Objects Served 
Select Statistics>Contents>Data. 
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0 






3-4 MB 


0 


30-40 MB 


0 






4-5 MB 


0 


40-50 MB 


0 






5-6 MB 


0 










6-7 MB 


0 










7-8 MB 


0 










8-9 MB 


0 


Objects in cache: 


304 





Figure 22-43: Contents Data Tab 



Help 



Event Logging 

Viewing the Event Log 

The event log contains all events that have occurred on the Proxy SG. Configure the level of detail 
available by selecting Maintenance>Event Logging>Level (see "Configuring Which Events to Log" on 
page 951 for details). 

To View the Event Log 
1. Select Statistics>Event Logging. 



Event log: END OF LOG 



2005-11-29 19: 
2005-11-29 20: 
2005-11-29 20: 
2005-11-29 21: 
2005-11-29 21: 
2005-11-29 22: 
2005-11-29 22: 
2005-11-29 22. 
2005-11-2 9 22: 
2005-11-29 22: 
2005-11-2 9 22. 
2005-11-29 23: 
2005-11-29 23: 



45 : 41+00: OOUTC 
00: 02+00: OOUTC 
33:29+00: OOUTC 
00: 01+00: OOUTC 
33:29+00: OOUTC 
00: 00+00: OOUTC 
04: 58+00: OOUTC 
04: 59+00: OOUTC 
05: 02+00: OOUTC 
05: 02+00: OOUTC 
33:28+00: OOUTC 
00: 00+00: OOUTC 
33: 28+00: OOUTC 



"Read/write mode entered frost 10.15 
"Snapshot sysinfo stats has fetched 
"NTP: Periodic query of server ntp . , 
"Snapshot sysinfo stats has fetched 
"NTP: Periodic query of server ntp.* 
"Snapshot sys inf o_s tats has fetched 
"Enabling- costpatibility stode for pr 
"Failed none for adstin ssh2" 0 46 
"Administrator login from 10.150.1. 
"Accepted password for admin ssh2" 
"NTP: Periodic query of server ntp . j 
"Snapshot sys inf o_s tats has fetched 
"NTP: Periodic query of server ntp., 



0 Poll lot new events [ Log start || << ]( >> |( Log end 

Figure 22-44: Event Viewer 
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2. Click Log start or Log end or the forward and back arrow buttons to move through the event list. 

3. (Optional) Click the Poll for new events checkbox to poll for new events that occurred while the log 
was being displayed. 

Note: The Event Log cannot be cleared. 



Bandwidth Management Statistics 

The bandwidth management statistics tabs (Current Class Statistics and Total Class Statistics) display 
the current packet rate and total number of packets served, the current bandwidth rate, and the total 
number of bytes served and packets dropped. 

Bandwidth management statistics are also available through the CLI. 



Current Class Statistics Tab 

The Current Class Statistics tab displays the following information for each bandwidth class: 

• Current Packet Rate: current packets-per-second (pps) value. 

• Current Bandwidth: current bandwidth in kilobits per second (Kbps). 

To View Current Bandwidth Management Class Statistics through the Management Console 
1. Go to Statistics>Bandwidth Management>Current Class Statistics. 

The high level bandwidth classes and their statistics are visible. 

Current Class Statistics Total Class Statistics 



rBandwidth Classes- 



Bandwidth Class 


| Current Packet Rate(pps) | 


Current Bandwidth(kbps) | 


• bridging 


0 


0 


• ftp 


0 


0 


• http 


a 


0 


• im 


0 


0 


1 streaming 


0 


0 


• P2P 


a 


0 


# service-info 


0 


0 


# socks 


0 


0 


* tcp-tunnel 


0 


0 



Help 

Figure 22-45: Current Class Statistics Tab 

2. To view the statistics of child bandwidth classes, double-click the folder icon of the parent class. 
The child classes become visible. A second double-click will close the folder. 
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Total Class Statistics Tab 

The Total Class Statistics tab displays the following information for each bandwidth class: 

• Packets: the total number of packets served. 

• Bytes: the total number of bytes served. 

• Drops: the total number of packets dropped. 

To View Total Bandwidth Management Class Statistics through the Management Console 
1. Go to Statistics>Bandwidth Management>Total Class Statistics. 

The high level bandwidth classes and their statistics are visible. 

Current Class Statistics Total Class Statistics 



rBandwidth Classes- 



Bandwidth Class | 


Packets 


Tl 


Bytes 


■■ 


Drops 


1 


• bridging 




0 




0 




0 


• ftp 




0 




0 




0 


• http 




0 




0 




0 


* im 




0 




0 




0 


I streaming 




0 




0 




0 


• P2p 




0 




0 




0 


* service-info 




0 




0 




0 


* socks 




0 




0 




0 


* tcp-tunnel 




0 




0 




0 



Help 

Figure 22-46: Total Class Statistics Tab 

2. To view the statistics of child bandwidth classes, double-click the folder icon of the parent class. A 
second double-click will close the folder. 

Bandwidth Management Statistics in the CLI 

To View Bandwidth Management Statistics through the CLI 

1 . To view all bandwidth management statistics, enter the following commands at the prompt: 
SGOS# (config) bandwidth-management 

SGOS# (config bandwidth-management) view statistics 

2. To view the BWM statistics for a specific class, enter the following command at the (config) 
command prompt: 

SGOS# (config bandwidth-management) view statistics bwm_class 
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Example 



SGOS# (config bandwidth-management) view statistics http 


Class Name: 


http 


Parent : 


<none> 


Minimum Bandwidth: 


unspecified 


Maximum Bandwidth: 


unlimited 


Priority : 


0 


Total Bytes: 


0 bytes 


Total Packets : 


0 pkts 


Dropped Packets : 


0 pkts 


Current Bandwidth: 


0 kbps 


Current Packet Rate : 


0 pps 


Queue Length : 


0 bytes 



where: 



Parent 


The class name of the parent of this class. 


Minimum Bandwidth 


The maximum bandwidth setting for this class. 


Maximum Bandwidth 


The minimum bandwidth setting for this class. 


Priority 


The priority level for this class. 


Total Bytes 


The total number of bytes served. 


Total Packets 


The total number of packets served. 


Dropped Packets 


Total number of packets dropped (packets in the queue that are 
dropped because the queue length is reached). 


Current Bandwidth 


Current bandwidth value (in kilobits per second). 


Current Packet Rate 


Current packets-per-second value. 


Queue Length 


Maximum length allowed for the queue of packets that lack available 
bandwidth but are waiting for bandwidth to become available. 



To Clear Bandwidth Management Statistics through the CLI 

1 . To clear bandwidth management statistics for all bandwidth management classes, enter the 
following command at the prompt: 

SGOS# clear-statistics bandwidth-management 

2. To clear bandwidth management statistics for a particular class, enter the following command at 
the prompt: 

SGOS# clear-statistics bandwidth-management class bandwidth_class_name 
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Access-Log Statistics 

Access-log statistics can be viewed from the Management Console or the CLI, although not all 
statistics you can view in the Management Console are available in the CLI. 

You can also view some access log statistics by navigating to Statistics>Advanced and clicking Access 
Log. Statistics you can view from Statistics>Advanced include: 

□ Show list of all logs: The access log manages multiple log objects internally. These are put together as 
one logical access log file when the file is uploaded. 

The show list shows the available internal log objects for easy access. To download part of the 
access log instead of the whole log file, click on the individual log object shown in the list. The 
latest log object can be identified by its timestamp. 

Note: If you have multiple access logs, each access log has its own list of objects. 

□ Show access log statistics: The statistics of an individual access log is shown. 

□ Show statistics of all logs: The statistics of all the access logs on the system are displayed in a single 
list. 

□ Show last N bytes in the log: The last N bytes in the log are shown. 

□ Show last part of log every time it changes: A stream of the latest log entries is shown on the page as 
they are written in the system. 

□ Show access log tail with optional refresh time: A refresh from the browser displays the latest log 
entries. 

□ Show access log objects: The statistics of individual access log objects are displayed. 

□ Show all access log objects: The statistics of all access log object are displayed in a single list. 

Viewing the Access Log Tail 

This option is not available through the CLI. 

To Display the Access Log Tail through the Management Console 

1. Select Statistics>Access Logging>Log Tail. 
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Log Tail Log Size | Upload Status 




2. From the Log drop-down list, select the log you want to view. 

3. Click Start Tail to display the access log tail. 

The ProxySG displays a maximum of 500 lines. Entries that pre-date these 500 lines are not 
displayed. 

4. Click Stop Tail to stop the display or Clear Tail to clear the display. 

Viewing the Log File Size 

The Log Size tab displays current log statistics: 

□ Whether the log is being uploaded (Table 22.3 describes upload statuses) 

□ The current size of all access log objects 

□ Disk space usage 

□ Last modified time 

□ Estimated size of the access log file, once uploaded 
Table 22.3: Log Writing Status Description 



Status 


Description 


active 


Log writing is active. 


active - early upload 


The early upload threshold has been reached. 


disabled 


An administrator has disabled logging. 


idle 


Log writing is idle. 


initializing 


The system is initializing. 
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Table 22.3: Log Writing Status Description 



shutdown 


The system is shutting down. 


stopped 


The access log is full. The maximum log size has been reached. 


unknown 


A system error has occurred. 



Estimated compressed size of the uploaded access log and ProxySG access log size might differ during 
uploading. This occurs because new entries are created during the log upload. 

To View the Access Log Size Statistic through the Management Console 
1. Select Statistics>Access Logging>Log Size. 



Log T ail 



Log Size 

Log: 



Upload Status 



Current log file: 

Log writing: 

Current size: 

T otal disk space used: 

Last modified: 

Estimate of upload log file size 
Compressed: 
Uncompressed: 



Active 

Log file is empty 
None 

2005-11-21 23:13:45+00:00UTC 

Nothing to upload 
Nothing to upload 



Help 

Figure 22-48: Checking the Log Size Statistics 
2. From the Log drop-down list, select a log to view. 

Viewing Access Logging Status 

The ProxySG displays the current access logging status on the Management Console. This includes 
separate status information about: 

□ The writing of access log information to disk 

□ The client the ProxySG uses to upload access log information to the remote server 

To View Access Logging Upload Status through the Management Console 
1. Select Statistics>Access Logging>Upload Status. 
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Log T ail 



Log Size Upload Status 



Log: 



main 



v 



- Status of last upload: 

Upload client: 
Connect time: 
Remote filename: 
Remote size: 
Maximum bandwidth: 
Current bandwidth: 
Last upload result: 



disabled 
never uploaded 
Never rotated 
Empty 

0.0 kilobytes/s 

N/A (Client not connected) 

Failure 



Help 

Figure 22-49: Viewing Upload Status Statistics 

2. Under Status of Last Upload, check the appropriate status information displayed in the Upload client 
field. 

3. Check the other status information. For information about the status, see the table below. 



Table 22.4: Upload Status Information 



Status 


Description 


Connect time 


The last time a client connection was made or attempted. 


Remote filename 


The most recent upload filename. If an access log was encrypted, only the 
encrypted access log file (the ENC file) displays. 


Remote size 


The current size of the upload file. If an access log was encrypted, only the 
encrypted access log file size (the ENC file) displays. The private key file (the 
DER file) varies, but is usually about 1 Kb. 


Maximum bandwidth 


The maximum bandwidth used in the current or last connection. 


Current bandwidth 


The bandwidth used in the last second (available only if currently connected). 


Final result 


The result of the last upload attempt (success or failure). This is available only if 
not connected. 



Viewing Access-Log Statistics through the CLI 

In the CLI, you can view all access log statistics at once, or you can view the statistics of a specific 
access log. For details of the meaning of these statistics, see "Viewing the Log File Size" on page 1014 
and "Viewing Access Logging Status” on page 1015. 
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To View Access Logging Statistics through the CLI 

1. To view the statistics for all access logs at once, enter the following command: 

SGOS# show access-log statistics 

2. To view the statistics for a specific access log, enter the following command: 

SGOS# show access -log statistics log_name 

The statistics for the access log Main are displayed below as an example: 



SGOS# (conf ig) show access-log 
Statistics : 

Access Log (main) Statistics: 
Log Manager Version 3 
Log entry lifetime counter: 
System Status: 

Log manager: 

Upload client: 

Log writer: 

Log reader: 

Log Information: 

Current log size: 

Early upload threshold: 
Maximum log size: 

Max size policy: 

Bytes in write buffer : 

Tail sockets in use : 
Modified time: 

Next Upload: 

Client type: 

Next attempt : 

Connect type : 

Connect reason: 

Estimated upload size: 
compressed : 
uncompressed : 

Upload format : 

Last Upload Attempt : 

Time : 

Maximum bandwidth: 

Result : 

Current/Last Upload File: 
Remote filename: 

Remote size: 



statistics main 



0 

enabled and running 

disabled 

idle 

idle 

0 bytes 
1736 MB 
2170 MB 
stop logging 
0 
0 

2004-08-26 22:10:49+00: 00UTC 
ftp 

uploading disabled 
daily upload 
regular upload 

nothing to upload 
nothing to upload 
gzip 

never uploaded 
0.00 KB/sec 
failure 

Never rotated 
0 bytes 
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Failover Statistics 

At any time, you can view statistics for any failover group you have configured on your system. 

Viewing Failover Status 

To View Failover Status 
1. Go to Statistics>Failover. 



Status 



Failover Group: 



10 . 9 . 16.150 



v 



Failover status: 

224 . 1 . 2.3 
10 . 9 . 16.150 
MASTER 
R (Real IP) 



Multicast address: 
Local address: 
State: 

Flags: 



| Help 

Figure 22-50: Failover Status Tab 

2. From the drop-down list, select the group whose statistics you want to view. 

The information displayed includes the multicast address, the local address, the state, and any flags, 
where V indicates the group name is a virtual IP address, R indicates the group name is a physical IP 
address, and M indicates this machine can be configured to be the master if it is available. 



Advanced Statistics 

A variety of system statistics are conveniently located in one place and accessible by clicking the links 
listed in the Advanced tab of the Management Console. 

To View System-Wide Advanced Statistics 
1. Select Statistics>Advanced. 
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Statistics 


General 
System Usage 
HTTP/FTP History 
IM History 
P2P History 
Streaming History 
SOCKS History 
■* Shell History 
Resources 
Efficiency 
Contents 
J Event Logging 
•* Bandwidth Mgmt. 
•> Access Logging 
Failover 
life. Advanced 


. ADP 

• Access Loa 

• Archive Confiauration 

• Authentication 

• Bridae 

• Cache Enaine 

• Content Filter Service 

• DNS 

• Diaanostics 

• Event loa 

• Exceptions 

• External-services 

• FIE 

• Failover 

• Forwardina 
. HTTP 

• Health Checks 

• 1CP 



Figure 22-51 : Advanced Tab 



2. Click the appropriate link for the service you want to view. 
A list of categories for that service will appear. 



Note: If you upgraded from SGOS 2.x or CacheOS 4.x and have log files generated by those 

versions, you can view or retrieve them through the Statistics>Advanced>Access Log>Show 
Old Logs URL. 



3. To view the statistics for a particular category, click that category's link. 

A window opens, detailing the relevant statistics. 

4. Close the window when you have finished viewing the statistics. 

5. To return to the list of links, either reselect Statistics>Advanced or click your browser's Back button. 
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The Blue Coat Systems Authentication and Authorization Agent (BCAAA) allows SGOS 4.x to 
manage authentication for Windows SSO realms and authentication and authorization for IWA, 
Netegrity SiteMinder realms, and Oracle COREid realms. The agent is installed and configured 
separately from SGOS 4.x and is available at the Blue Coat Website. 

The BCAAA service must be installed on a domain controller or member server, allowing the ProxySG 
to access domain controllers. The BCAAA service authenticates users in all domains trusted by the 
computer on which it is running. A single installation of the BCAAA service can support multiple 
ProxySG appliances. 

Starting with SGOS 4.2, multiple versions of the BCAAA service can run on the same machine. This 
allows you to use the same machine to support versions of the ProxySG that have different BCAAA 
version requirements. 

The BCAAA install directory can include multiple executable programs. 

□ The program bcaaa . exe (bcaaa on Solaris) handles connections from ProxySG appliances and 
hands them off to the correct version of the processor. 

□ The program bcaaa -99. exe (bcaaa - 9 9 on Solaris) handles communication with versions of the 
ProxySG prior to SGOS 4.2. 

□ The program bcaaa - 100 . exe (bcaaa - 10 0 on Solaris) handles communication with SGOS 4.2. 

□ The program bcaaa - 110 . exe (bcaaa - 110 on Solaris) handles communication with SGOS 4.2.2 

When a new version of the BCAAA service is installed in the same installation directory as earlier 
versions, the earlier versions are not removed. 

This allows ProxySG appliances that were communicating with the old version to continue to operate. 

Using the BCAAA Service 

Several realms use the BCAAA service: 

□ IWA: The BCAAA service talks directly to an Integrated Windows Authentication (IWA) or NTLM 
server. When using IWA, the network typically chooses automatically whether to use NTLM or 
Kerberos (IWA). 

• NTLM: NTLM is a subset of IWA, meant to be used with Windows NT systems. 

• IWA: If using Kerberos, the BCAAA service must share a secret with a Kerberos server (called 
a KDC) and register an appropriate Service Principal Name (SPN). Lor information on sharing 
a secret and registering an SPN, see "Creating Service Principal Names for IWA Realms" on 
page 1031. 
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□ SiteMinder and COREid: When a SiteMinder or COREid realm is referenced in policy, a BCAAA 
process is created. The ProxySG then sends a configuration request that describes the servers to 
use. The BCAAA service logs in to the appropriate servers and determines configuration 
information to be passed back to the ProxySG (such as the kind of credentials required). 
Responses from the SiteMinder and COREid policy servers are translated into appropriate 
BCAAA protocol responses and returned to the ProxySG. 

Before you can use the BCAAA service with SiteMinder or COREid, you must configure the 
appropriate ProxySG realm to work with the SiteMinder or COREid servers. The realm can be 
configured from the SiteMinder or COREid configuration tabs in the Management Console or 
from the CLI. 



Note: Each (active) SiteMinder realm on the ProxySG should reference a different agent on the 

Policy Server. 



For specific information about configuring the SiteMinder realm to work with the Netegrity 
policy servers, see "Section H: Netegrity SiteMinder" on page 419. For specific information about 
configuring the COREid realm to work with Oracle COREid Access Servers, see "Section I: Oracle 
COREid" on page 434. 

□ Windows Single Sign-on (SSO): The BCAAA service is used to supply mappings for IP addresses 
to logged on users. The Windows SSO realm can use domain controller querying, or client 
querying, or both domain controller and client querying to determine the logged-on user. 



Note: To use domain controller querying, you must configure the sso . ini file to enable it and 

to add the domain controllers you want to query. For information on configuring the 
sso . ini file, see "Section B: Windows Single Sign-on Authentication". 



Operating system requirements are: 

□ IWA, COREid, and Windows SSO: Windows® 2000 or later. 

□ SiteMinder: Windows 2000 or later or Solaris™ 5.8 or 5.9. 

The appendix discusses: 

□ "Installing the BCAAA Service on a Windows System” 

□ "Installing the BCAAA Service on a Solaris System” 

□ "Creating Service Principal Names for IWA Realms" 

□ "Troubleshooting Authentication Agent Problems” 

□ "Common BCAAA Event Messages" 

Performance Notes 

Blue Coat recommends that the Windows BCAAA service be installed on a dedicated Windows 
machine. Installation of any other non-essential software might degrade the BCAAA service 
performance, which in turn degrades the user experience. 
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This is because the BCAAA server is in the client data path for accessing protected resources. Users 
make client requests to the ProxySG, which in turn proxies authentication requests to the BCAAA. 
service. The user must wait for the authentication request to complete before the ProxySG responds to 
the user with a protected resource. 



Installing the BCAAA Service on a Windows System 

Before you begin, create a regular user account for the BCAAA services on the Active Directory server, 
and give the account a password. 



Note: If you have an existing CAASNT service on your system, it is stopped and deleted as part 

of the BCAAA service installation procedure. 



To Install the Authentication Agent 

1. Download the file from the Blue Coat download site at https://download.bluecoat.com/ 

2. Launch the install wizard. 




Figure A-1 : BCAAA Installation Wizard Launch 
3. Click Next to select the destination folder. 
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Figure A-2: Destination Folder for the BCAAA Service Application 



Note: When doing an upgrade from one version of the BCAAA service to another version of the 

BCAAA service, you must install into the previous BCAAA folder to retain your settings. 
If you install to a different folder, a new .ini file with default settings is created. 

When upgrading from CAASNT to BCAAA, the settings from CAASNT are copied to the 
new installation directory. 



4. Click Browse to select a different destination folder for the BCAAA service. 

5. Click Next to accept the default and select the port number. 




Figure A-3: Selecting BCAAA Port Number 

6. The port number must match the port number you specify on the ProxySG for the BCAAA 
service. The default is 16101. 
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7. Click Next to specify the SSL requirements. 




Figure A-4: SSL Requirements 

8. The default is that SSL is Permitted, allowing both SSL and non-SSL connections. This setting 
must be compatible with the setting on the ProxySG. 

9. Click Next to specify the subject of the SSL certificate. 



BCAAA Setup 



Blue®Coat 



Specify Ihe subject (CN) in the certificate. This will be looked up in the 
certificate store; if creating, this will be the subject of the self-signed 
certificate. 

Default is the hostname of the machine on which the agent is running. 



0 N 




[ <Back ||i Next > H [ Cancel | 

Figure A-5: Specifying the Subject of the Certificate 

10. Specify the subject of the certificate. 

The BCAAA service looks up the specified subject in the service's certificate store. If it finds the 
subject, it uses it instead of generating a new certificate. If not, it generates a self-signed certificate 
with that subject. This generated certificate can be saved (as specified on the next screen). 

11. Click Next to specify save options for the certificate. 
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Figure A-6: Saving the Generated Certificate 

12. Click Next to specify whether the ProxySG must provide a valid certificate when connecting to the 
BCAAA service. 




Figure A-7: Verify ProxySG Certificate 

13. To force the ProxySG to provide a valid certificate to connect to the BCAAA service, select the Yes 
radio button. The default is No. 

14. (Optional) If you are using Windows SSO or Novell SSO realms, you might want to have the 
BCAAA service run as the LocalSystem account or as a domain user. The default is no. If you 
select no and click Next, the summary window displays. If you select yes, the configuration screen 
for the domain user displays. 
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jqj BCAAA Setup 



Seivice Account 



Blue£*3Coat 



BCAAA can be configured to run as the LocalSystem account or as a domain 
user. Running as a domain user is required for certain configurations. 

Please see the documentation for details. 

Do you want to configure BCAAA to run as a domain user? 

C* Yes 

(* No (Use LocalSystem account ) 



< Back 



[ Next i> 



Cancel 



Figure A-8: Run as LocalSystem Account or Domain User 

15. (Optional). If you selected yes to configure the service account, click Next. The configuration 
screen for the Service Account displays. Add a user name and the associated password. 




Figure A-9: Service Account Configuration Information 

16. Click Next to view the summary of the changes you made. 

17. Click Install to install the BCAAA service using the settings you configured. 
When installation completes, the final BCAAA screen displays. 
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Figure A-10: Completing BCAAA Installation 

To Modify Settings or Uninstall the Authentication Agent 

1 . Launch the install wizard. 




Figure A-1 1 : Applications Maintenance Page 

2. Click Modify to re-enter the installation wizard; click Remove to uninstall the BCAAA service from 
the system 



Note: For instructions on using the installation wizard, see "Installing the BCAAA Service on a 

Windows System" on page 1023. 
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Figure A-12: Uninstalling the BCAAA Service 
3. Click Next to start the procedure. 




Figure A-13: Uninstallation Notice 
4. Click Finish to exit the uninstall application. 

To View the Application Event Log 

The BCAAA service logs all errors to the Windows Application Event Log under the name BCAAA. 

1 . Launch the Event Viewer. 

2. Doubleclick the information message BCAAA service to see that the BCAAA service has been 
automatically started. 
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To View the BCAAA Service 

The BCAAA service is listed under Services under the name BCAAA. 

1 . Launch Services 

2. Right-click on BCAAA and select Properties to manage the service. For example, to make the 
BCAAA service start only manually, set the Startup Type to Manual. (Automatic is the default 
setting.) 

Completing Setup for the BCAAA Service 

Once the BCAAA service is installed, you must complete BCAAA setup by configuring the service to 
work with Windows. 

To Configure the BCAAA Service 

1. Open the properties panel for the BCAAA service 

a. Select the Log-on tab. 

b. Change the account to the one you created for the BCAAA service, and enter the 
password. 

c. Click OK. You might be warned that the account has been given logon as service privileges. 

2. Verify in Local Security Policy's User Rights Assignment folder that the BCAAA Service user 
account has been added to the list of the Log on as a service policy. 



Note: You must have modify/write privileges in the BCAAA folder. 



3. (Optional) If group-based authorization is being done, then: 

a. Ensure that the user impersonation privilege is set for the SERVICE group. For more 
information setting the user impersonation privilege, see: 

http: / /support. microsoft.com/ default. aspx?scid=kb;en-us;831218. 

b. Ensure that the Active Directory computer account running the BCAAA service has the 
Trust computer for delegation configuration property enabled. 

4. For all users authenticating to the ProxySG using IWA realms, user accounts in the Active 
Directory must have permission to log onto the machine where the BCAAA server is running. 

a. Go to the user's account properties user account tab. 

b. Click the Log On To. . . button to specify the domain that computers can log onto. If the 
network environment restricts users to specific computers, then each user must have the 
name of the host running the BCAAA service added to their list. 

5. If the basic credentials are enabled on the IWA realm and the BCAAA service is running as a 
domain user, the BCAAA domain user account must also have the right to "act as part of the 
operating software". 
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a. Go to the Local Security Policy's User Rights Assignment folder. 

b. Select the "Act as part of the operating system" and add the BCAA domain user. Make 
sure you add the username, including its domain "domain\bcaaa_domain_user" (you can 
also browse to select the right BCAA A domain user account). 

6. You might have to reboot the BCAAA machine for the policies to take effect. 

Installing the BCAAA Service on a Solaris System 

To install the BCAAA service on Solaris, complete the following instructions. You must be root to 
complete installation. 



Note: For successful installation of the BCAAA service on a Solaris system, you will need 

libstdc + + . so . 5”, usually installed with package SFWgcc32 
gcc-3.2 - GNU Compiler Collection Version 3.2 



1. Download the shell script to your system. 

2. Execute the shell script: 

# sh bcaaa-version_number-SOLARIS-install . sh 

3. Answer the questions to install the service on your Solaris system. A sample session is shown 
below: 

Enter a path to a scratch directory [/tmp] : 

Install Blue Coat Systems Authentication and Authorization Agent (BCAAA) ? 

(y/n) y 

Enter user that should own the installed files [root] 

Enter group for the installed files [root] 

/usr/local/bin/bcaaa installed 
/us r/ local /bin/bcaaa- 110 installed 

Libraries installed in /usr/local/lib/BlueCoatSystems/ 

/usr/ local /etc/bcaaa .ini installed 

If you use inetd, append the following line to /etc/services 

bcaaa 16101/tcp #Blue Coat Systems Authentication 

Agent 

If you use inetd, append the following line to /etc/inetd . conf , then signal 
inetd to re-read the configuration file 

If you use something else, make the equivalent changes 
bcaaa stream tcp nowait root /usr/local/bin/bcaaa bcaaa -c 
/usr /local /etc /bcaaa .ini 
Installation complete 

Creating Service Principal Names for IWA Realms 

For the BCAAA service to participate in an IWA Kerberos authentication exchange, it must share a 
secret with the Kerberos server (called a KDC) and have registered an appropriate Service Principal 
Name (SPN). 
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You can share the secret two ways: 

□ LocalSystem 

In this approach the SPN is registered with the NetBIOS name of the machine on which the 
BCAAA service is running. The BCAAA service runs under LocalSystem (the default for 
services), and uses the machine's shared secret. 

The primary advantage of this approach is convenience: it works with the default settings for 
service installation. The disadvantage is that only one BCAAA server is allowed for the realm, so 
you cannot have a backup server. 



Note: Handling of the shared secret is done by Windows when the machine joins the domain; 

there is no explicit knowledge of the shared secret by SGOS or by the BCAAA service. 



□ Service Account 

You can also create a service account for the BCAAA service and register the SPN on the service 
account. This allows multiple servers to run the BCAAA service all using the same account. 

The advantage is the ability to have a backup BCAAA server. The disadvantage is that it requires 
additional configuration on the Active Directory server, the domain controller, and on each 
BCAAA machine. It is also less secure, since the BCAAA account password is shared among 
multiple machines. 

To Share a Secret by Creating a Service Account 



Note: All steps require administrator privileges. 



1 . Go to the Active Directory server. 

2. Create an account for use by the BCAAA service. 

3. Create a password. 

4. On the domain controller, open the domain policy console and modify the Local Policy's user 
rights assignment and allow the account you created in on the Active Directory to have the right 
to "act as the operating system." 

5. Run the following command: 

setspn -A HTTP/FQDN-of -host name 

where name is the name of the account created in step 1 and the FQDN is the virtual URL 

that was set in the authentication realm. For example: 

setspn -A HTTP/krbproxy . authteam . Waterloo . bluecoat . com 

authteam\krb-bcaaa 



Note: The setspn application might have to be downloaded from Microsoft. It is installed by 

default in program f iles\resource kit. 
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(Optional) To Create a Group Account (a BCAAA user account capable of doing group-based 
authorization): 

If group-based authorization is being done, then: 

1. Ensure that the user impersonation privilege is set for the SERVICE group. 

Note: For information on setting the user impersonation privilege, see 

http:/ / support.microsoft.com/ default.aspx?scid=kb;en-us;831218 



2. Ensure that the Active Directory computer account running the BCAAA service has the "Trust 
computer for delegation" configuration property enabled. 

On each machine where you want to run the BCAAA service: 

1. Install the BCAAA service as normal. 

2. Open the Properties panel for the BCAAA service and select the Logon tab. Change the account to 
the one you created on the Active Directory server, and enter the password. When you click OK, it 
might warn you that the account has been granted "Log On as A Service right”. 

3. Change the security on the BCAAA install directory to give the account created on the Active 
Directory server full control. 

All these machines now share the same secret with the KDC and can decrypt service tickets intended 
for the service described by the SPN. 

Troubleshooting Authentication Agent Problems 

This section describes some common problems you might encounter when setting up or using the 
BCAAA service on a Windows platform. 

To troubleshoot the BCAAA service, launch the event viewer. 

The Properties pane displays, providing information about the status of the BCAAA service at that 
time. Note the Type and the Event ID. The description below the Type/Event ID lists the problem. 
You can often find more information about the problem and suggestions for its solution in "Common 
BCAAA Event Messages" on page 1034. 

Common problems: 

□ If an attempt to start the BCAAA service is issued when the BCAAA service is already started, the 
following error message displays: 

The requested service has already been started. 

□ If another application is using the same port number as the BCAAA service, the following 
messages are displayed: 

The BCAAA service coidd not be started. 

A system error has occurred. 

System error 10048 has occurred. 
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Only one usage of each socket address (protocol/netzvork address/port) is normally permitted. 

Common BCAAA Event Messages 

Following are the most common event messages that can be logged to the Windows Application 
Event Log. Most of the event messages not listed here are error status messages returned by Win32 
function calls. When a Win32 call fails, the error code and error text containing the reason for the error 
displays in the event log under the name BCAAA. 

To View the BCAAA Event Log 

1. Right click on My Computer and select Manage. 

2. Select System Tools>Event Viewer>Application. 



For each BCAAA event message, the event message is displayed along with the event number. 
Table A.1 : BCAA Event Messages 



Message 

ID 


Message 


Description 


200 


Various messages 


The associated message provides information about a 
condition that is not an error. 


300 


Various messages 


The associated message warns about an unexpected 
condition that does not prevent operation. 


400 


Various messages 


The associated message describes an error condition 
that prevents normal operation. 


1001 


Authentication Agent service started: 
port=# threads=# socket=0x# 
process id=# agent version=# 

Proxy SG Appliance version=# 


This indicates successful startup and provides 
information about the agent. 


1002 


Authentication Agent stopped 


This indicates normal shutdown of the service. 


1003 


ProxySG Appliance (a.b.c.d) connected; 
Process # spawned as # 


This indicates a ProxySG has connected to the agent 
(Windows only). 


1004 


ProxySG Appliance agent process exited 
(normal logout) 


This indicates normal logout by a ProxySG. 


1005 


Process %d has terminated, 
ExitCode=0x#, link=0x# 


This indicates an unexpected termination of an agent 
process (Windows only). 


1006 


Service dispatcher exited. 


This indicates an unexpected termination of the 
service dispatcher. 


1007 


CreateNamedPipe failed, pipe='%s' 


The agent dispatcher could not create the named pipe 
for the reason given. 


1008 


ConnectNamedPipe failed, pipe='%s' 


The agent process could not obtain the information 
from the dispatcher on the named pipe for the reason 
given. 
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Table A. 1: BCAA Event Messages (Continued) 



Message 

ID 


Message 


Description 


1009 


WriteFile failed, pipe='%s' 


The dispatcher could not write information to the 
named pipe for the reason given. 


1011 


CreateThread (ProcessTimerThread) 
failed 


The dispatcher could not create its timer thread. 


1012 


Failed to create ProxySG Appliance 
process '%s' 


The dispatcher could not create an agent process. 


1019 


Various 


The dispatcher was unable to determine the exit 
status of an agent process. 


1020 


Terminating ProxySG Appliance process 
#, ProcNum=# Handle=0x# 


An agent process was active when the Windows 
service was shut down. 


1022 


Various 


The associated message reports the status of a 
ProxySG login attempt. 


1101 


BasicAuth: CloseHandle failed; user 
'xxWxx' 


The agent was unable to close the login handle for the 
specified user. 


1102 


Username: '%s\\%s' too long 


The ProxySG offered the specified username, which is 
too long. 


1106 


Various 


An attempted authentication using BASIC credentials 
failed for the reason given. 


1107 


User Right ’Act as part of the operating 
system' required for Basic 
Authentication 


The agent does not have the necessary privileges to 
do BASIC authentication 


1108 


Various 


The agent was unable to determine information about 
the user for the reason given. 


1202 


Unable to create GroupsOflnterest 
mutex 'xx' - already exists 


The agent could not create the Windows mutex 
needed for group authorization checks because it 
already exists. 


1203 


Unable to create GroupsOflnterest 
mutex 'xx 


The agent could not create the Windows mutex 
needed for group authorization checks. 


1204 


OpenMutex failed for AuthGroups 
mutex '%s', group='%s' 


The agent was unable to open the Windows mutex 
needed for group authorization checks. 


1205 


Various 


The agent was unable to close the Windows mutex 
named for the reason given. 


1207 


GetAclInformation failed 


The agent was unable to obtain ACL information 
needed to do group authorization checks. 


1209 


GetKernelObjectSecurity failed for 
AuthGroup='%s' 


The agent was unable to obtain security information 
about the specified group. 
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Table A. 1: BCAA Event Messages (Continued) 



Message 

ID 


Message 


Description 


1210 


SetKernelObjectSecurity failed 


The agent was unable to set up security information 
for the reason specified. 


1211 


InitializeSecurityDescriptor failed 


The agent was unable to initialize the security 
descriptor for the reason specified. 


1212 


GetSecurityDescriptorDacl failed 


The agent was unable to get the discretionary access 
control list (DACL) for the reason specified. 


1213 


SetSecurityDescriptorDacl failed 


The agent was unable to set the discretionary access 
control list (DACL) for the reason specified. 


1214 


InitializeAcl failed 


The agent was unable to initialize the access control 
list (ACL) for the reason specified. 


1215 


GetUserName failed for 
AuthGroup='%s' 


The agent was unable to determine the username 
while processing the specified group. 


1217 


GetAce failed for AuthGroup='%s' 


The agent was unable to get the access control entry 
(ACE) for the specified group. 


1218 


AddAce failed 


The agent was unable to add the necessary access 
control entry (ACE) for the reason specified. 


1219 


AddAccessAllowedAce failed 


The agent was unable to add the necessary "access 
allowed" access control entry (ACE). 


1220 


Could not establish groups-of-interest: 
result=0x## 


The agent was unable to initialize groups-of-interest 
checking. 


1221 


AuthGroup '%s' does not exist 


The specified group does not exist. 


1222 


IWA RevertSecurityContext failed, 
user='%s' 


The agent could not revert the security context for the 
specified user. 


1223 


BASIC: RevertToSelf failed, user=’%s' 


The agent could not revert the security context for the 
specified user. 


1224 


Error calling OpenProcessToken 


The agent's call to OpenProcessToken failed for the 
specified reason. 


1225 


Error calling LookupPrivilege Value 


The agent could not get information about a needed 
privilege. 


1226 


Error calling AdjustTokenPrivileges 


The agent could not adjust its privileges as required. 


1227 


ImpersonateLoggedOnUser failed; 
Group access denied for user '%s' 


The agent could not impersonate the specified user. 


1228 


IWA: ImpersonateSecurityContext 
failed; Group access denied for user '%s' 


The agent could not impersonate the specified user. 
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Table A. 1: BCAA Event Messages (Continued) 



Message 

ID 


Message 


Description 


1301 


NOTE: Pending ContextLink=### timed 
out; deleting SecurityContext h=## 
TS=##now=## 


The ProxySG did not provide a response to a 
challenge quickly enough. 


1302 


Various 


An authentication request from a ProxySG referenced 
an in-progress request that has timed out or does not 
exist. 


1304 


Various 


The agent was unable to delete a security context for 
the reason given. 


1305 


AcceptSecurityContext failure, 
SEC_E_INVALID_HANDLE, 
ContextLink=### count=# 


The agent was provided with an invalid context 
handle. 


1306 


Various 


The client provided an invalid token to the 
authentication system. 


1308 


AcceptSecurityContext failure, 
ContextLink=# count=#, detail=#(xxx) 


Windows rejected the authentication attempt for the 
reason given. 


1310 


Various 


This records the failure of NTLM authentication or 
group authorization. 


1311 


3:Failed NTLM Authentication for user: 
'%s' 


This records the failure of NTLM authentication; the 
user name was supplied by the client. 


1312 


Various 


The agent could not determine the username from the 
NTLM type 3 message supplied by the client. 


1313 


Invalid Type3 message 


The client provided an NTLM type 3 message that 
was invalid. 


1314 


BASE64_Decode: Length of token 
exceeds max (%d) 


The client provided an NTLM token that was too 
long. 


1316 


Unsupported version in request: 
%d(0x%x) 


The ProxySG sent a request with an unsupported 
version number. 


1401 


Various 


The agent lost communication with the ProxySG. 


1403 


Various 


The agent is aborting for the reason given. 


1402 


Unexpected thread 0 exit 


The agent exited unexpectedly. 


1404 


Unable to get Processlnfo from parent 
process. 


The agent could not obtain its information from the 
dispatcher. 


1405 


CreateFile failed, pipe='xx’ 


The agent could not create a handle for the 
dispatcher's named pipe. 


1406 


WaitNamedPipe failed, pipe='%s’ 


The agent could not wait for the dispatcher's named 
pipe. 
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Table A. 1: BCAA Event Messages (Continued) 



Message 

ID 


Message 


Description 


1407 


ReadFile failed, pipe='%s' 


The agent could not read information from the 
dispatcher’s named pipe. 


1409 


Various 


The agent could not create the specified thread for the 
reason given. 


1412 


Various 


The agent could not create a required Windows event 
object. 


1413 


AuthMethod 'xxs' not supported: 
returning _AuthResult=0x## 


The ProxySG requested an unsupported 
authentication mechanism. 


1414 


Various 


The specified request is unsupported. 


1500 


Various 


The agent has a problem with memory allocation; 
typically this means there is not enough memory. 


1501 


Unable to allocate memory for ProcLink 
buffer. 


The agent could not allocate some needed memory. 


1502 


Unable to allocate memory for 
ContextLink buffer. 


The agent could not allocate some needed memory. 


1503 


Various 


The agent was unable to allocate needed memory. 


1604 


Service dispatch failed 


The Windows service dispatcher failed to start. 


1605 


RegisterServiceCtrlHandler failed 


The agent dispatcher was unable to register the 
service control handler. 


1608 


SetServiceStatus failed, 
g_StatusHandle=%d 


The agent was unable to set the service's status. 


1610 


Unsupported service control code: # 


Windows sent a service control code that the agent 
does not support. 


1701 


WSASocket failed 


The agent could not create a Windows socket for the 
reason given. 


1702 


WSAStartup failed. 


The agent could not start the Windows socket for the 
reason given. 


1703 


Various 


The agent could not send data to the ProxySG for the 
reason given. 


1704 


Various 


The agent could not receive data from the ProxySG 
for the reason given. 


1705 


accept failed 


The agent dispatcher could not initialize to accept 
new connections. 


1706 


bind failed, PortNumber=# 


The agent dispatcher could not bind to the specified 
port. 
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Table A. 1: BCAA Event Messages (Continued) 



Message 

ID 


Message 


Description 


1707 


listen failed. 


The agent dispatcher could not listen for new 
connections. 


1708 


Various 


Windows reported an event wait failure to the agent 
while doing I/O on the socket. 


1709 


The agent is already running or the 
agent's port # is in use by another 
process 


Some other process is already using the port needed 
by the agent. 


1710 


WSARecv failed reading bytes from 
socket 


Windows reported an error when the agent tried to 
receive bytes from the ProxySG. 


1711 


WSASend failed sending bytes to socket. 


Windows reported an error when the agent tried to 
send bytes to the ProxySG. 


1712 


Various 


A socket 1/ O operation did not complete successfully. 


1801 


Error calling AcquireCredentialsHandle 


The agent could not acquire its credentials from 
Windows. 


1803 


Various 


The agent could not load a needed library (DLL). 


1804 


Various 


The agent could not locate the needed services in a 
library (DLL). 


1805 


Unsupported SSPI Windows platform; 
PlatformId=# 


The reported Windows platform is not supported for 
NTLM authentication. 


1806 


Error calling QueryContextAttributes 


The agent could not determine the authenticated 
user's security attributes. 


1807 


QuerySecurityPackagelnfo failed 


The agent could not get needed security information 
from Windows. 


1808 


Max Token size too long (#); max size is # 


The client supplied an NTLM token that is too long. 


1809 


FreeContextBuffer failed 


An attempt to free the NTLM context buffer failed. 


1811 


Username 'x\\y' too long 


The reported user name is too long. 


1901 


Admin Services Error: Access denied to 
domain/user/group information 


The agent was unable to access necessary 
information. 


1902 


Admin Services Error: Invalid computer 
from which to fetch information 


The computer to be used to get security information is 
invalid. 


1903 


Admin Services Error: Group not found 


The requested group could not be found. 


1904 


Various 


The reported error was encountered while browsing. 


1905 


Admin services error: could not translate 
context to Unicode 


The requested object for browsing could not be 
translated to Unicode 
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Table A. 1: BCAA Event Messages (Continued) 



Message 

ID 


Message 


Description 


1906 


Admin service out of memory 


The browsing service ran out of memory. 


1907 


Search request object too long: # > # 


The requested object for browsing is too long. 


2000 


AcquireCredentialsHandle failed: Ox# 


The agent could not acquire the credentials needed 
for an SSL session. 


2001 


Various 


The agent was unable to negotiate an SSL session for 
the reason given. 


2002 


Various 


An I/O error occurred during an SSL session . 


2003 


Various 


The specified cryptographic error occurred during an 
SSL session. 


2004 


Various 


The specified problem occurred with a certificate 
during SSL negotiation. 


2100 


NETBIOS name not available for domain 
%S. 


The BCAAA service could not find a NetBIOS name 
for the given Active Directory domain. 


2101 


Could not enumerate domains. 


An error occurred when attempting to discover the 
Windows domains available for querying. 


2102 


Cannot find domain controllers for 
domain %s. 


The domain controllers for the given domain could 
not be found. 


2200 


Cannot query domain controller %s. 


The given domain controller could not be queried for 
the current set of logon connections. 


2201 


Could not read header. 


The backup file of SSO logons could not be read. 


2202 


Unsupported serialize version %d. 


The version of backup file of SSO logons did not 
match the expected version. 


2203 


Could not write header. 


The backup file of SSO logons could not be written. 


2204 


Various 


An error was encountered when attempting to back 
up the set of SSO logons. 


2205 


Various. 


An error was encountered when attempting to 
configure the Windows SSO BCAAA support. 


2206 


Cannot find IP address for host %s. 


It was not possible to discover the IP address of the 
given DNS or NetBIOS computer name. 


2207 


Various. 


An SSO synchronization connection has been lost. 


2300 


Various. 


An LDAP error was received from the eDirectory 
LDAP server 


2301 


Novell LDAP search failure . 


The eDirectory server could not be searched. 
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The ProxySG can create access logs in one of the following formats: 

□ "Custom or W3C ELFF Format” 

□ "SQUID-Compatible Format” 

n "NCSA Common Access Log Format” 

ELFF is a log format defined by the W3C that contains information about Windows Media and 
RealProxy logs. 

The ProxySG can create access logs with any one of six formats. Four of the six are reserved formats 
and cannot be configured. However, you can create additional logs using custom or ELFF format 
strings. 

When using an ELFF or custom format, a blank field is represented by a dash character. When using 
the SQUID or NCSA log format, a blank field is represented according to the standard of the format. 



Custom or W3C ELFF Format 

The W3C Extended Log File Format (ELFF) is a subset of the Blue Coat Systems format. The ELFF 
format is specified as a series of space delimited fields. Each field is described using a text string. The 
types of fields are described in Table B.l. 



Table B.1: Field Types 



Field Type 


Description 


Identifier 


A type unrelated to a specific party, such as date and time. 


prefix- identifier 


Describes information related to a party or a transfer, such as c-ip (client's IP) or 
sc -bytes (how many bytes were sent from the server to the client) 


prefix (header) 


Describes a header data field. The valid prefixes are: 


c = Client 
s = Server 
r = Remote 
sr = Server to Remote 


cs = Client to Server 
sc = Server to Client 
rs = Remote to Server 



ELFF formats are created by selecting a corresponding custom log format using the table below. 
Unlike the Blue Coat custom format, ELFF does not support character strings and require a space 
between fields. 

Selecting the ELFF format does the following: 

□ Puts one or more W3C headers into the log file. Each header contains the following lines: 
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#Software: SGOS x.x.x 
#Version : 1.0 

#Date : 2002-06-06 12:12:34 
#Fields:date time cs-ip... 

□ Changes all spaces within fields to + or %2 0. The ELFF standard requires that spaces only be 
present between fields. 



ELFF formats are described in Table B.2. 

Table B.2: Blue Coat Custom Format and Extended Log File Format 



Blue Coat Custom 
Format 


Extended Log File Format 


Description 


space character 


N/A 


Multiple consecutive spaces are compressed to a 
single space. 


% 


- 


Denotes an expansion field. 


%% 


- 


Denotes '%' character. 


%a 


c-ip 


IP address of the client. 


%b 


sc-bytes 


Number of bytes sent from appliance to client. 


%c 


rs (Content -Type) 


Response header: Content-Type. 


%d 


s- supplier -name 


Hostname of the upstream host (not available for 
a cache hit). 


%e 


time -taken 


Time taken (in milliseconds) to process the 
request. 


%f 


sc -filter-category 


Content filtering category of the request URL. 


%g 


timestamp 


UNIX- type timestamp. 


%h 


c-dns 


Hostname of the client (uses the client's IP address 
to avoid reverse DNS). 


%i 


cs-uri 


The 'log' URL. 


%j 


- 


[Not used.] 


%k 


- 


[Not used.] 


%1 


x-bluecoat- special -empty 


Resolves to an empty string. 


%m 


cs-method 


Request method used from client to appliance. 


%n 


- 


[Not used.] 


%o 


- 


[Not used.] 


%p 


r-port 


Port from the outbound server URL. 


%q 


- 


[Not used.] 


%r 


cs- request -line 


First line of the client's request. 
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Table B.2: Blue Coat Custom Format and Extended Log File Format (Continued) 



Blue Coat Custom 
Format 


Extended Log File Format 


Description 


%S 


sc-status 


Protocol status code from appliance to client. 


%t 


gmttime 


GMT date and time of the user request in format: 
[DD/MM/YYYY:hh:mm:ss GMT], 


%U 


cs-user 


Qualified username for NTLM. Relative username 
for other protocols. 


%v 


cs-host 


Hostname from the client's request URL. If URL 
rewrite policies are used, this field's value is 
derived from the 'log' URL. 


%w 


s-action 


What type of action did the appliance take to 
process this request. 


%x 


date 


GMT Date in YYYY-MM-DD format. 


%y 


time 


GMT time in HH:MM:SS format. 


%Z 


s-icap-status 


ICAP response status. 


%A 


cs (User-Agent) 


Request header: User-Agent. 


%B 


cs-bytes 


Number of bytes sent from client to appliance. 


%C 


cs (Cookie) 


Request header: Cookie. 


%D 


s-supplier-ip 


IP address used to contact the upstream host (not 
available for a cache hit). 


%E 


- 


[Not used.] 


%F 


- 


[Not used.] 


%G 


- 


[Not used.] 


%H 


s -hierarchy 


How and where the object was retrieved in the 
cache hierarchy. 


%I 


s-ip 


IP address of the appliance on which the client 
established its connection. 


%J 


- 


[Not used.] 


%K 


- 


[Not used.] 


%L 


localtime 


Local date and time of the user request in format: 
[DD/MMM/YYYY:hh:mm:ss +nnnn]. 


%M 


- 


[Not used.] 


%N 


s - computername 


Configured name of the appliance. 


%0 


- 


[Not used.] 
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Table B.2: Blue Coat Custom Format and Extended Log File Format (Continued) 



Blue Coat Custom 
Format 


Extended Log File Format 


Description 


%P 


s-port 


Port of the appliance on which the client 
established its connection. 


%Q 


cs-uri-query 


Query from the 'log' URL. 


%R 


cs (Referer) 


Request header: Referer. 


%S 


s-sitename 


Service used to process the transaction. 


%T 


duration 


Time taken (in seconds) to process the request. 


%U 


cs-uri-path 


Path from the 'log' URL. Does not include query. 


%V 


cs-version 


Protocol and version from the client's request, e.g. 
HTTP/ 1.1. 


%W 


sc -filter-result 


Content filtering result: Denied, Proxied, or 
Observed. 


%X 


cs (X-Forwarded-For) 


Request header: X-Forwarded-For. 


%Y 


- 


[Not used.] 


%Z 


s-icap-info 


ICAP response information. 



Example Access Log Formats 

Squid log format: %g %e %a %w/%s %b %m %i %u %H/%d %c 

NCSA common log format: %h %1 %u %t "%r" %s %b 

NCSA extended log format: %h %1 %u %L "%r" %s %b "%R" "%A" 

Microsoft IIS format: %a, %x, %y, %S, %N, %I, %e, %b, %B, %s, 0, %m, %U, - 

The Blue Coat custom format allows any combination of characters and format fields. Multiple spaces 
are compressed to a single space in the actual access log. You can also enter a string, such as My 
default is %d. The ProxySG goes through such strings and finds the relevant information. In this 
case, that information is %d. 

SQUID-Compatible Format 

The SQUID-compatible format contains one line for each request. For SQUID-1.1, the format is: 

time elapsed remotehost code/status bytes method URL rfc931 
peerstatus/peerhost type 

For SQUID-2, the columns stay the same, though the content within might change a little. 

Action Field Values 

Table B.3 describes the possible values for the action field. 
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Table B.3: Action Field Values 



Value 


Description 


ACCELERATED 


(SOCKS only) The request was handed to the appropriate protocol agent for 
handling. 


ALLOWED 


An FTP method (other than the data transfer method) is successful. 


DENIED 


Policy denies a method. 


FAILED 


An error or failure occurred. 


LICENSE_EXPIRED 


(SOCKS only) The request could not be handled because the associated license 
has expired. 


TUNNELED 


Successful data transfer operation. 


TCP_ 


Refers to requests on the HTTP port. 


T C P_AUTH_H I T 


The requested object requires upstream authentication, and was served from the 
cache. 


T C P_AUTH_M I S S 


The requested object requires upstream authentication, and was not served from 
the cache. This is part of CAD (Cached Authenticated Data). 


TCP_AUTH_REDIRECT 


The client was redirected to another URL for authentication. 


TCP_CLIENT_REFRESH 


The client forces a revalidation with the origin server with a Pragma : 
no- cache. If the server returns 3 04 Not Modified, this appears in the 
Statistics : Efficiency file as In Cache, verified Fresh. 


TCPJDENIED 


Access to the requested object was denied by a filter. 


TCP_ERR_MISS 


An error occurred while retrieving the object from the origin server. 


TCP_HIT 


A valid copy of the requested object was in the cache. 


TCP_LOOP 


The current connection is dropped because the upstream connection would 
result in a looped connection. 


TCP_MEM_HIT 


The requested object was, in its entirety, in RAM. 


TCP_MISS 


The requested object was not in the cache. 


TCP_NC_MISS 


The object returned from the origin server was non-cacheable. 


T C P_P ART I AL_M I S S 


The object is in the cache, but retrieval from the origin server is in progress. 


TCP_POLICY_REDIRECT 


The client was redirected to another URL due to policy. 


TCP_REFRESH_HIT 


A GIMS request to the server was forced and the response was 3 04 Not 
Modified, this appears in the Statistics: Efficiency file as In Cache , 
verified Fresh. 


TCP_REFRESH_MISS 


A GIMS request to the server was forced and new content was returned. 


T C P_RE S CAN_H I T 


The requested object was found in the cache but was rescanned because the 
virus-scanner-tag-id in the object was different from the current scanner tag. 
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Table B.3: Action Field Values (Continued) 



Value 


Description 


TCP_SPLASHED 


The user was redirected to a splash page. 


TCP_SWAPFAIL 


The object was believed to be in the cache, but could not be accessed. 


TCP_TUNNELED 


The CONNECT method was used to tunnel this request (generally proxied 
HTTPS). 


UDP_ 


Refers to requests on the 1CP port (3130). 


UDP_DENIED 


Access was denied for this request. 


UDP_HIT 


A valid copy of the requested object was in the cache. This value is also used 
with ICP queries. 


UDP_INVALID 


The ICP request was corrupt, short, or otherwise unintelligible. 


UDP_MISS 


The requested object was not in the cache. This value is also used with ICP 
queries. 


UDP_MISS_NOFETCH 


An ICP request was made to this cache for an object not in the cache. The 
requestor was informed that it could not use this cache as a parent to retrieve the 
object. (This is not supported at this time.) 


UDP_OBJ 


An ICP request was made to this cache for an object that was in cache, and the 
object was returned through UDP. (This is not supported at this time. This 
functionality is deprecated in the current ICP specification.) 



NCSA Common Access Log Format 

The common log format contains one line for each request. The format of each log entry is shown 
below: 



remotehost rfc931 authuser [date] "request" status bytes 
Each field is described in Table B.4. 

Table B.4: Common Log Format Entries 



Field Name 


Description 


remotehost 


DNS hostname or IP address of remote server. 


rf c931 


The remote log name of the user. This field is always — . 


authuser 


The username as which the user has authenticated himself. 


[date] 


Date and time of the request. 


"request" 


The request line exactly as it came from the client. 


status 


The HTTP status code returned to the client. 


bytes 


The content length of the document transferred. 
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Access Log Filename Formats 

Table B.5 details the specifiers for the access log upload filenames. 
Table B.5: Specifiers for the Access Log Upload Filenames 



Specifier 


Description 


%% 


Percent sign. 


%a 


Abbreviated weekday name. 


%A 


Full weekday name. 


%b 


Abbreviated month name. 


%B 


Full month name. 


%c 


The certificate name used for encrypting the log file (expands to nothing in non-encrypted case). 


%c 


The ProxySG name. 


%d 


Day of month as decimal number (01 - 31). 


%f 


The log name. 


%H 


Hour in 24-hour format (00 - 23). 


%i 


First IP address of the ProxySG, displayed in x x x x format, with leading zeros removed. 


%i 


Hour in 12-hour format (01 - 12). 


%j 


Day of year as decimal number (001 - 366). 


%i 


The fourth part of the ProxySG's IP address, using three digits (001 . 002 . 003 . 004) 


%m 


Month as decimal number (01 - 12). 


%M 


Minute as decimal number (00 - 59). 


%p 


Current locale's A.M./P.M. indicator for 12-hour clock. 


%S 


Second as decimal number (0 0 - 5 9). 


%U 


Week of year as decimal number, with Sunday as first day of week (0 0 - 53). 


%W 


Weekday as decimal number (0 - 6; Sunday is 0). 


%w 


Week of year as decimal number, with Monday as first day of week (00 - 53). 


%y 


Year without century, as decimal number (0 0 - 9 9). 


%Y 


Year with century, as decimal number. 


%z, %Z 


Time-zone name or abbreviation; no characters if time zone is unknown. 
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Fields Available for Creating Access Log Formats 

The following table lists all fields available for creating access log formats. When creating an ELFF 
format, you must use the values from the ELFF column. When creating a custom format, you can use 
values from the ELFF, CPL, or custom column. 



Table B.6: Access Log Substitutions 



ELFF 


CPL 


Custom 


Description 


Category: bytes 


cs-bodylength 






Number of bytes in the body 
(excludes header) sent from client 
to appliance 


cs-bytes 




%B 


Number of bytes sent from client 
to appliance 


cs-headerlength 






Number of bytes in the header 
sent from client to appliance 


rs-bodylength 






Number of bytes in the body 
(excludes header) sent from 
upstream host to appliance 


rs-bytes 






Number of bytes sent from 
upstream host to appliance 


rs-headerlength 






Number of bytes in the header 
sent from upstream host to 
appliance 


sc-bodylength 






Number of bytes in the body 
(excludes header) sent from 
appliance to client 


sc-bytes 




%b 


Number of bytes sent from 
appliance to client 


sc-headerlength 






Number of bytes in the header 
sent from appliance to client 


sr-bodylength 






Number of bytes in the body 
(excludes header) sent from 
appliance to upstream host 


sr-bytes 






Number of bytes sent from 
appliance to upstream host 


sr-headerlength 






Number of bytes in the header 
sent from appliance to upstream 
host 




Category: connection 
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Table B.6: Access Log Substitutions (Continued) 



ELFF 


CPL 


Custom 


Description 


cs-ip 


proxy.address 




IP address of the destination of 
the client's connection 


c-connect-type 






The type of connection made by 
the client to the appliance — 
'Transparent' or 'Explicit' 


c-dns 




%h 


Hostname of the client (uses the 
client's IP address to avoid 
reverse DNS) 


x-cs-dns 


client.host 




The hostname of the client 
obtained through reverse DNS. 


c-ip 


client.address 


%a 


IP address of the client 


x-cs-netbios-computer- 

name 


netbios.computer-name 




The NetBIOS name of the 
computer. This is an empty string 
if the query fails or the name is 
not reported. When using the 
$(netbios.*) substitutions to 
generate the username, the client 
machines must react to a NetBIOS 
over TCP/IP node status query. 


x-cs-netbios-computer- 

domain 


netbios.computer-domain 




The name of the domain to which 
the computer belongs. This is an 
empty string if the query fails or 
the name is not reported. When 
using the $(netbios.*) 
substitutions to generate the 
username, the client machines 
must react to a NetBIOS over 
TCP/IP node status query. 


x-cs-netbios-messenger- 

username 


netbios.messenger-username 




The name of the logged-in user. 
This is an empty string if the 
query fails or the name is not 
reported. It is also empty there is 
more than one logged-in user. 
When using the $(netbios.*) 
substitutions to generate the 
username, the client machines 
must react to a NetBIOS over 
TCP/IP node status query. 
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Table B.6: Access Log Substitutions (Continued) 



ELFF 


CPL 


Custom 


Description 


x-cs-netbios-messenger- 

usernames 


netbios.messenger-usernames 




A comma-separated list of the all 
the messenger usernames 
reported by the target computer. 
This is an empty string if the 
query fails, or no names are 
reported. When using the 
$(netbios.*) substitutions to 
generate the username, the client 
machines must react to a NetBIOS 
over TCP/IP node status query. 


x-cs-session-username 


session.username 




The username associated with 
this session as reported by 
RADIUS accounting. This is an 
empty string if no session is 
known. 


x-cs-ident-username 


ident.username 




The username associated with 
this session as returned from an 
ident query. This is an empty 
string if no session is known. 


x-cs-connection-negotiated- 

cipher 


client.connection.negotiated_cipher 




OpenSSL cipher suite negotiated 
for the client connection 


x-cs-connection-negotiated- 

cipher-strength 


client.connection.negotiated_cipher. 

strength 




Strength of the OpenSSL cipher 
suite negotiated for the client 
connection 


x-cs-connection-negotiated- 

cipher-size 






Ciphersize of the OpenSSL cipher 
suite negotiated for the client 
connection 


x-cs-connection-negotiated- 

ssl-version 


client.connection.negotiated_ssl_ 

version 




Version of the SSL protocol 
negotiated for the client 
connection 


r-dns 






Hostname from the outbound 
server URL 


r-ip 






IP address from the outbound 
server URL 


r-port 




%p 


Port from the outbound server 
URL 


r-supplier-dns 






Hostname of the upstream host 
(not available for a cache hit) 


r-supplier-ip 






IP address used to contact the 
upstream host (not available for a 
cache hit) 
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Table B.6: Access Log Substitutions (Continued) 



ELFF 


CPL 


Custom 


Description 


r-supplier-port 






Port used to contact the upstream 
host (not available for a cache hit) 


sc-adapter 


proxy.card 




Adapter number of the client's 
connection to the Appliance 


sc-connection 






Unique identifier of the client's 
connection (i.e. SOCKET) 


x-bluecoat-server- 

connection-socket-errno 


server_connection.socket_errno 




Error message associated with a 
failed attempt to connect to an 
upstream host 


s-computername 


proxy.name 


%N 


Configured name of the 
appliance 


s-cormect-type 






Upstream connection type 
(Direct, SOCKS gateway, etc.) 


s-dns 






Hostname of the appliance (uses 
the primary IP address to avoid 
reverse DNS) 


s-ip 




%I 


IP address of the appliance on 
which the client established its 
connection 


s-port 


proxy.port 


%P 


Port of the appliance on which 
the client established its 
connection 


s-sitename 




%S 


Service used to process the 
transaction 


x-module-name 


module_name 




The SGOS module that is 
handling the transaction 


s-supplier-ip 




%D 


IP address used to contact the 
upstream host (not available for a 
cache hit) 


s-supplier-name 




%d 


Hostname of the upstream host 
(not available for a cache hit) 


x-bluecoat-transaction-id 


transaction.id 




Unique per-request identifier 
generated by the appliance (note: 
this value is not unique across 
multiple appliances) 


x-bluecoat-appliance- 

name 


appliance.name 




Configured name of the 
appliance 


x-bluecoat-appliance- 

primary-address 


appliance.primary_address 




Primary IP address of the 
appliance 
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Table B.6: Access Log Substitutions (Continued) 



ELFF 


CPL 


Custom 


Description 


x-bluecoat-proxy-primary-a 

ddress 


proxy.primary_address 




Primary IP address of the 
appliance 


x-appliance-serial-number 


appliance.serial_number 




The serial number of the 
appliance 


x-appliance-mc-certificate-fi 

ngerprint 


appliance.mc_certificate_fingerprint 




The fingerprint of the 
management console certificate 


x-appliance-product-name 


appliance.product_name 




The product name of the 
appliance — e.g. Blue Coat SG4xx 


x-appliance-product-tag 


appliance.product_tag 




The product tag of the appliance 
— e.g. SG4xx 


x-appliance-full-version 


appliance.full_version 




The full version of the SGOS 
software 


x-appliance-first-mac- 

address 


appliance.first_mac_address 




The MAC address of the first 
installed adapter 


x-client-address 






IP address of the client 


x-client-ip 






IP address of the client 


x-rs-connection-negotiated- 

cipher 


server.connection.negotiated_cipher 




OpenSSL cipher suite negotiated 
for the client connection 


x-rs-connection-negotiated- 

cipher-strength 


server.connection.negotiated_cipher. 

strength 




Strength of the OpenSSL cipher 
suite negotiated for the server 
connection 


x-rs-connection-negotiated- 

cipher-size 






Ciphersize of the OpenSSL cipher 
suite negotiated for the server 
connection 


x-rs-connection-negotiated- 

ssl-version 


server.connection.negotiated_ssl_ 

version 




Version of the SSL protocol 
negotiated for the server 
connection 




Category: dns 


x-dns-cs-transport 


dns.client_transport 




The transport protocol used by 
the client connection in a DNS 
query 


x-dns-cs-address 


dns.request.address 




The address queried in a reverse 
DNS lookup 


x-dns-cs-dns 


dns.request.name 




The hostname queried in a 
forward DNS lookup 
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Table B.6: Access Log Substitutions (Continued) 



ELFF 


CPL 


Custom 


Description 


x-dns-cs-opcode 


dns.request.opcode 




The DNS OPCODE used in the 
DNS query 


x-dns-cs-qtype 


dns.request.type 




The DNS QTYPE used in the DNS 
query 


x-dns-cs-qclass 


dns . request . class 




The DNS QCLASS used in the 
DNS query 


x-dns-rs-rcode 


dns.response.code 




The DNS RCODE in the response 
from upstream 


x-dns-rs-a-records 


dns.response.a 




The DNS A RRs in the response 
from upstream 


x-dns-rs-cname-records 


dns.response.cname 




The DNS CNAME RRs in the 
response from upstream 


x-dns-rs-ptr-records 


dns.response.ptr 




The DNS PTR RRs in the 
response from upstream 




Category: im 


x-im-buddy-id 






Instant messaging buddy ID 


x-im-buddy-name 






Instant messaging buddy display 
name 


x-im-buddy-state 






Instant messaging buddy state 


x-im-chat-room-id 






Instant messaging identifier of 
the chat room in use 


x-im-chat-room-members 






The list of chat room member Ids 


x-im-chat-room-type 






The chat room type, one of 
'public' or 'public', and possibly 
'invite_only', 'voice' and/ or 
'conference' 


x-im-client-info 






The instant messaging client 
information 


x-im-user-agent 


im.user_agent 




The instant messaging user agent 
string 


x-im-file-path 






Path of the file associated with an 
instant message 


x-im-file-size 






Size of the file associated with an 
instant message 
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Table B.6: Access Log Substitutions (Continued) 



ELFF 


CPL 


Custom 


Description 


x-im-http-gateway 






The upstream HTTP gateway 
used for IM (if any) 


x-im-message-opcode 


im.message. opcode 




The opcode utilized in the instant 
message 


x-im-message-reflected 


im.message.reflected 




Indicates whether or not the IM 
message was reflected. 


x-im-message-route 






The route of the instance message 


x-im-message-size 






Length of the instant message 


x-im-message-text 






Text of the instant message 


x-im-message-type 






The type of the instant message 


x-im-method 






The method associated with the 
instant message 


x-im-user-id 






Instant messaging user identifier 


x-im-user-name 






Display name of the client 


x-im-user-state 






Instant messaging user state 




Category: p2p 


x-p2p-client-bytes 






Number of bytes from client 


x-p2p-client-info 






The peer-to-peer client 
information 


x-p2p-client-type 


p2p.client 




The peer-to-peer client type 


x-p2p-peer-bytes 






Number of bytes from peer 




Category: packets 


c-pkts-lost-client 






Number of packets lost during 
transmission from server to client 
and not recovered at the client 
layer via error correction or at the 
network layer via UDP resends. 


c-pkts-lost-cont-net 






Maximum number of 
continuously lost packets on the 
network layer during 
transmission from server to client 


c-pkts-lost-net 






Number of packets lost on the 
network layer 
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Table B.6: Access Log Substitutions (Continued) 



ELFF 


CPL 


Custom 


Description 


c-pkts-received 






Number of packets from the 
server (s-pkts-sent) that are 
received correctly by the client on 
the first try 


c-pkts-recovered-ECC 






Number of packets repaired and 
recovered on the client layer 


c-pkts-recovered-resent 






Number of packets recovered 
because they were resent via 
UDP. 


c-quality 






The percentage of packets that 
were received by the client, 
indicating the quality of the 
stream 


c-resendreqs 






Number of client requests to 
receive new packets 


s-pkts-sent 






Number of packets from the 
server 




Category: req_rsp_line 


cs-method 


method 


%m 


Request method used from client 
to appliance 


x-cs-http-method 


http. method 




HTTP request method used from 
client to appliance. Empty for 
non-HTTP transactions 


cs-protocol 


client.protocol 




Protocol used in the client's 
request 


cs-request-line 


http .request_line 


%r 


First line of the client's request 


x-cs-raw-headers-count 


request.raw_headers.count 




Total number of 'raw' headers in 
the request 


x-cs-raw-headers-length 


request.raw_headers. length 




Total length of 'raw' headers in 
the request 


cs-version 


request.version 


%V 


Protocol and version from the 
client's request, e.g. HTTP/1.1 


x-bluecoat-proxy-via-http-v 

ersion 


proxy.via_http_version 




Default HTTP protocol version of 
the appliance without protocol 
decoration (e.g. 1.1 for HTTP/1.1) 


x-bluecoat-redirect-location 


redirect.location 




Redirect location URL specified 
by a redirect CPL action 
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Table B.6: Access Log Substitutions (Continued) 



ELFF 


CPL 


Custom 


Description 


rs-response-line 






First line (a.k.a. status line) of the 
response from an upstream host 
to the appliance 


rs-status 


response.code 




Protocol status code of the 
response from an upstream host 
to the appliance 


rs-version 


response.version 




Protocol and version of the 
response from an upstream host 
to the appliance, e.g. HTTP/1.1 


sc-status 




%s 


Protocol status code from 
appliance to client 


x-bluecoat-ssl-failure- 

reason 


ssl_failure_reason 




Upstream SSL negotiation failure 
reason 


x-cs-http-version 


http.request.version 




HTTP protocol version of request 
from the client. Does not include 
protocol qualifier (e.g. 1.1 for 
HTTP/1.1) 


x-cs-socks-ip 


socks. destination_address 




Destination IP address of a 
proxied SOCKS request 


x-cs-socks-port 


socks.destination_port 




Destination port of a proxied 
SOCKS request 


x-cs-socks-method 


socks.method 




Method of a proxied SOCKS 
request 


x-cs-socks-version 


socks .version 




Version of a proxied SOCKS 
request. 


x-cs-socks-compression 






Used compression in SOCKS 
client side connection. 


x-sr-socks-compression 






Used compression in SOCKS 
server side connection. 


x-sc-http-status 


http.response.code 




HTTP response code sent from 
appliance to client 


x-rs-http-version 


http.response.version 




HTTP protocol version of 
response from the upstream host. 
Does not include protocol 
qualifier (e.g. 1.1 for HTTP/1.1) 


x-sc-http-version 






HTTP protocol version of 
response to client. Does not 
include protocol qualifier (e.g. 1.1 
for HTTP/1.1) 
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Table B.6: Access Log Substitutions (Continued) 



ELFF 


CPL 


Custom 


Description 


x-sr-http-version 






HTTP protocol version of request 
to the upstream host. Does not 
include protocol qualifier (e.g. 1.1 
for HTTP/1.1) 


sc(Content-Encoding) 






Client Response header: 
Content-Encoding 


sr(Accept-Encoding) 






Server Request header: 
Accept-Encoding 




Category: special__token 


x-bluecoat-special-amp 


amp 




The ampersand character 


x-bluecoat-special-apos 


apos 




The apostrophe character (a.k.a. 
single quote) 


x-bluecoat-special-cr 


cr 




Resolves to the carriage return 
character 


x-bluecoat-special-crlf 


crlf 




Resolves to a carriage return/line 
feed sequence 


x-bluecoat-special-empty 


empty 


%1 


Resolves to an empty string 


x-bluecoat-special-esc 


esc 




Resolves to the escape character 
(ASCII HEX IB) 


x-bluecoat-special-gt 


gt 




The greater-than character 


x-bluecoat-special-lf 


it 




The line feed character 


x-bluecoat-special-lt 


it 




The less-than character 


x-bluecoat-special-quot 


quot 




The double quote character 


x-bluecoat-special-slash 


slash 




The forward slash character 




Category: ssl 


x-rs-certificate-hostname 


server.certificate.hostname 




Hostname from the server's SSL 
certificate 


x-rs-certificate-hostname- 

categories 






All content categories of the 
server's SSL certificate's 
hostname 
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Table B.6: Access Log Substitutions (Continued) 



ELFF 


CPL 


Custom 


Description 


x-rs-certificate-hostname- 

categories-policy 






All content categories of the 
server's SSL certificate's 
hostname that are defined by 
CPL. 


x-rs-certificate-hostname- 

categories-local 






All content categories of the 
server's SSL certificate's 
hostname that are defined by a 
Local database. 


x-rs-certificate-hostname- 

categories-bluecoat 






All content categories of the 
server's SSL certificate's 
hostname that are defined by 
Blue Coat Web Filter. 


x-rs-certificate-hostname- 

categories-provider 






All content categories of the 
server's SSL certificate's 
hostname that are defined by the 
current 3rd-party provider. 


x-rs-certificate-hostname- 

categories-qualified 






All content categories of the 
server's SSL certificate's 
hostname, qualified by the 
provider of the category. 


x-rs-certificate-hostname- 

category 


server.certificate.hostname.category 




Single content category of the 
server's SSL certificate's 
hostname 


x-rs-certificate-valid-from 






Date from which the certificate 
presented by the server is valid 


x-rs-certificate-valid-to 






Date until which the certificate 
presented by the server is valid 


x-rs-certificate-serial- 

number 






Serial number of the certificate 
presented by the server 


x-rs-certificate-issuer 






Issuer of the certificate presented 
by the server 


x-rs-certificate-signature- 

algorithm 






Signature algorithm in the 
certificate presented by the server 


x-rs-certificate-pubkey- 

algorithm 






Public key algorithm in the 
certificate presented by the server 


x-rs-certificate-version 






Version of the certificate 
presented by the server 


x-rs-certificate-subject 


server.certificate.subject 




Subject of the certificate 
presented by the server 
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ELFF 


CPL 


Custom 


Description 


x-cs-certificate-common- 

name 


client . certificate . common_name 




Common name in the client 
certificate 


x-cs-certificate-valid-from 






Date from which the certificate 
presented by the client is valid 


x-cs-certificate-valid-to 






Date until which the certificate 
presented by the client is valid 


x-cs-certificate-serial- 

number 






Serial number of the certificate 
presented by the client 


x-cs-certificate-issuer 






Issuer of the certificate presented 
by the client 


x-cs-certificate-signature- 

algorithm 






Signature algorithm in the 
certificate presented by the client 


x-cs-certificate-pubkey- 

algorithm 






Public key algorithm in the 
certificate presented by the client 


x-cs-certificate-version 






Version of the certificate 
presented by the client 


x-cs-certificate-subject 


client . certificate . subject 




Subject of the certificate 
presented by the client 


x-rs-certificate-validate- 

status 






Result of validating server SSL 
certificate 


x-rs-certificate-observed- 

errors 






Errors observed in the server 
certificate 




Category: status 


x-bluecoat-release-id 


release.id 




The release ID of the Proxy SG 
operating system 


x-bluecoat-release-version 


release.version 




The release version of the 
ProxySG operating system 


cs-categories 






All content categories of the 
request URL 


cs-categories-external 






All content categories of the 
request URL that are defined by 
an external service. 


cs-categories-policy 






All content categories of the 
request URL that are defined by 
CPL. 
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ELFF 


CPL 


Custom 


Description 


cs-categories-local 






All content categories of the 
request URL that are defined by a 
Local database. 


cs-categories-bluecoat 






All content categories of the 
request URL that are defined by 
Blue Coat Web Filter. 


cs-categories-provider 






All content categories of the 
request URL that are defined by 
the current 3rd-party provider. 


cs-categories-qualified 






All content categories of the 
request URL, qualified by the 
provider of the category. 


cs-category 






Single content category of the 
request URL (a.k.a. 
sc-filter-category) 


cs-uri-categories 






All content categories of the 
request URL 


cs-uri-categories-external 






All content categories of the 
request URL that are defined by 
an external service. 


cs-uri-categories-policy 






All content categories of the 
request URL that are defined by 
CPL. 


cs-uri-categories-local 






All content categories of the 
request URL that are defined by a 
Local database. 


cs-uri-categories-bluecoat 






All content categories of the 
request URL that are defined by 
Blue Coat Web Filter. 


cs-uri-categories-provider 






All content categories of the 
request URL that are defined by 
the current 3rd-party provider. 


cs-uri-categories-qualified 






All content categories of the 
request URL, qualified by the 
provider of the category. 


cs-uri-category 






Single content category of the 
request URL (a.k.a. 
sc-filter-category) 


x-cs(Referer)-uri-categories 






All content categories of the 
Referer header URL 
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ELFF 


CPL 


Custom 


Description 


x-cs(Referer)-uri-categories- 

policy 






All content categories of the 
Referer header URL that are 
defined by CPL. 


x-cs(Referer)-uri-categories- 

local 






All content categories of the 
Referer header URL that are 
defined by a Local database. 


x-cs(Referer)-uri-categories- 

bluecoat 






All content categories of the 
Referer header URL that are 
defined by Blue Coat Web Filter. 


x-cs(Referer)-uri-categories- 

provider 






All content categories of the 
Referer header URL that are 
defined by the current 3rd-party 
provider. 


x-cs(Referer)-uri-categories- 

qualified 






All content categories of the 
Referer header URL, qualified by 
the provider of the category. 


x-cs(Referer)-uri-category 






Single content category of the 
Referer header URL (a.k.a. 
sc-filter-category) 


r-hierarchy 






How and where the object was 
retrieved in the cache hierarchy. 


sc-filter-category 


category 


%f 


Content filtering category of the 
request URL 


sc-filter-result 




%W 


Deprecated content filtering 
result: Denied, Proxied or 
Observed 


s-action 




%w 


What type of action did the 
Appliance take to process this 
request. 


s-cpu-util 






Average load on the proxy's 
processor (0%-100%) 


s-hierarchy 




%H 


How and where the object was 
retrieved in the cache hierarchy. 


s-icap-info 




%Z 


ICAP response information 


s-icap-status 




%z 


ICAP response status 


x-bluecoat-surfcontrol-categ 

ory-id 






The SurfControl specific content 
category ID. 


x-bluecoat-surfcontrol-is-de 

nied 






T if the transaction was denied, 
else 'O' 
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ELFF 


CPL 


Custom 


Description 


x-bluecoat-surfcontrol-is- 

proxied 






'O' if transaction is explicitly 
proxied, T if transaction is 
transparently proxied 


x-bluecoat-surfcontrol- 

reporter-id 






Specialized value for SurfControl 
reporter 


x-bluecoat-surfcontrol- 

reporter-v4 






The SurfControl Reporter v4 
format 


x-bluecoat-surfcontrol- 

reporter-v5 






The SurfControl Reporter v5 
format 


x-bluecoat-websense- 

category-id 






The Websense specific content 
category ID 


x-bluecoat-websense- 

keyword 






The Websense specific keyword 


x-bluecoat-websense- 

reporter-id 






The Websense specific reporter 
category ID 


x-bluecoat-websense-status 






The Websense specific numeric 
status 


x-bluecoat-websens e-user 






The Websense form of the 
username 


x-bluecoat-websense- 

reporter-protocol-3 






The Websense reporter format 
protocol version 3 


x-exception-company-name 


exception.company_name 




The company name configured 
under exceptions 


x-exception-contact 


exception.contact 




Describes who to contact when 
certain classes of exceptions 
occur, configured under 
exceptions (empty if the 
transaction has not been 
terminated) 


x-exception-details 


exception.details 




The configurable details of a 
selected policy-aware response 
page (empty if the transaction has 
not been terminated) 


x-exception-header 


exception.header 




The header to be associated with 
an exception response (empty if 
the transaction has not been 
terminated) 
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ELFF 


CPL 


Custom 


Description 


x-exception-help 


exception.help 




Help text that accompanies the 
exception resolved (empty if the 
transaction has not been 
terminated) 


x-exception-id 


exception.id 




Identifier of the exception 
resolved (empty if the transaction 
has not been terminated) 


x-exception-last-error 


exception.last_error 




The last error recorded for the 
current transaction. This can 
provide insight when unexpected 
problems are occurring (empty if 
the transaction has not been 
terminated) 


x-exception-reason 


exception.reason 




Indicates the reason why a 
particular request was terminated 
(empty if the transaction has not 
been terminated) 


x-exception-sourcefile 


exception.sourcefile 




Source filename from which the 
exception was generated (empty 
if the transaction has not been 
terminated) 


x-exception-sourceline 


exception.sourceline 




Source file line number from 
which the exception was 
generated (empty if the 
transaction has not been 
terminated) 


x-exception-summary 


exception.summary 




Summary of the exception 
resolved (empty if the transaction 
has not been terminated) 


x-exception-category- 

review-message 


exception.category_review_message 




Exception page message that 
includes a link allowing content 
categorization to be reviewed 
and/ or disputed. 


x-exception-category- 

review-url 


exception.category_review_url 




URL where content 
categorizations can be reviewed 
and/or disputed. 


x-patience-javascript 


patiencejavascript 




Javascript required to allow 
patience responses 


x-patience-progress 


patience_progress 




The progress of the patience 
request 


x-patience-time 


patience_time 




The elapsed time of the patience 
request 
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ELFF 


CPL 


Custom 


Description 


x-patience-url 


patience_url 




The url to be requested for more 
patience information 


x-virus-id 


icap_virus_id 




Identifier of a vims if one was 
detected 


x-virus-details 


icap_virus_details 




Details of a virus if one was 
detected 


x-icap-error-code 


icap_error_code 




ICAP error code 


x-icap-error-details 


icap_error_details 




ICAP error details 




Category: streaming 


audiocodec 






Audio codec used in stream. 


avgbandwidth 






Average bandwidth (in bits per 
second) at which the client was 
connected to the server. 


charmelURL 






URL to the .nsc file 


c-buffercount 






Number of times the client 
buffered while playing the 
stream. 


c-bytes 






An MMS-only value of the total 
number of bytes delivered to the 
client. 


c-cpu 






Client computer CPU type. 


c-hostexe 






Host application 


c-hostexever 






Host application version number 


c-os 






Client computer operating 
system 


c-osversion 






Client computer operating 
system version number 


c-playerid 






Globally unique identifier 
(GUID) of the player 


c-playerlanguage 






Client language-country code 


c-playerversion 






Version number of the player 


c-rate 






Mode of Windows Media Player 
when the last command event 
was sent 
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ELFF 


CPL 


Custom 


Description 


c-starttime 






Timestamp (in seconds) of the 
stream when an entry is 
generated in the log file. 


c-status 






Codes that describe client status 


c-totalbuffertime 






Time (in seconds) the client used 
to buffer the stream 


filelength 






Length of the file (in seconds). 


filesize 






Size of the file (in bytes). 


protocol 






Protocol used to access the 
stream: mms, http, or asfm. 


s-totalclients 






Clients connected to the server 
(but not necessarily receiving 
streams). 


transport 






Transport protocol used (UDP, 
TCP, multicast, etc.) 


videocodec 






Video codec used to encode the 
stream. 


x-cache-info 






Values: UNKNOWN, 
DEMAND_MISS, 
DEMAND_HIT, 
DEMAND_PASSTHRU, 
LIVE_SPLIT, LIVE_PASSTHRU 


x-duration 






Length of time a client played 
content prior to a client event (FF, 
REW, Pause, Stop, or jump to 
marker). 


x-wm-c-dns 






Hostname of the client 
determined from the Windows 
Media protocol 


x-wm-c-ip 






The client IP address determined 
from the Windows Media 
protocol 


x-cs-streaming-client 


streaming.client 




Type of streaming client in use 
(windows_media, real_media, or 
quicktime). 


x-rs-streaming-content 


streaming.content 




Type of streaming content served, 
(e.g. windows_media, quicktime) 


x-streaming-bitrate 


bitrate 




The reported client-side bitrate 
for the stream 
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CPL 


Custom 


Description 




Category: time 


connect-time 






Total ms required to connect to 
the origin server 


date 


date.utc 


%x 


GMT Date in YYYY-MM-DD 
format 


dnslookup-time 






Total ms cache required to 
perform the DNS lookup 


duration 




%T 


Time taken (in seconds) to 
process the request 


gmttime 




%t 


GMT date and time of the user 
request in format: 
[DD/MM/YYYY:hh:mm:ss 
GMT] 


x-bluecoat-day-utc 


day.utc 




GMT/UTC day (as a number) 
formatted to take up two spaces 
(e.g. 07 for the 7th of the month) 


x-bluecoat-hour-utc 


hour.utc 




GMT/UTC hour formatted to 
always take up two spaces (e.g. 
01 for 1AM) 


x-bluecoat-minute-utc 


minute.utc 




GMT/UTC minute formatted to 
always take up two spaces (e.g. 
01 for 1 minute past) 


x-bluecoat-month-utc 


month.utc 




GMT /UTC month (as a number) 
formatted to take up two spaces 
(e.g. 01 for January) 


x-bluecoat-monthname-utc 


monthname.utc 




GMT/UTC month in the 
short-form string representation 
(e.g. Jan for January) 


x-bluecoat-second-utc 


second.utc 




GMT/UTC second formatted to 
always take up two spaces (e.g. 
01 for 1 second past) 


x-bluecoat-weekday-utc 


weekday.utc 




GMT/UTC weekday in the 
short-form string representation 
(e.g. Mon for Monday) 


x-bluecoat-year-utc 


year.utc 




GMT/UTC year formatted to 
always take up four spaces 
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ELFF 


CPL 


Custom 


Description 


localtime 




%L 


Local date and time of the user 
request in format: 
[DD/MMM/YYYY:hh:mm:ss 
+nnnn] 


x-bluecoat-day 


day 




Localtime day (as a number) 
formatted to take up two spaces 
(e.g. 07 for the 7th of the month) 


x-bluecoat-hour 


hour 




Localtime hour formatted to 
always take up two spaces (e.g. 
01 for 1AM) 


x-bluecoat-minute 


minute 




Localtime minute formatted to 
always take up two spaces (e.g. 
01 for 1 minute past) 


x-bluecoat-month 


month 




Localtime month (as a number) 
formatted to take up two spaces 
(e.g. 01 for January) 


x-bluecoat-monthname 


monthname 




Localtime month in the 
short-form string representation 
(e.g. Jan for January) 


x-bluecoat-second 


second 




Localtime second formatted to 
always take up two spaces (e.g. 
01 for 1 second past) 


x-bluecoat-weekday 


weekday 




Localtime weekday in the 
short-form string representation 
(e.g. Mon for Monday) 


x-bluecoat-year 


year 




Localtime year formatted to 
always take up four spaces 


time 


time.utc 


%y 


GMT time in HH:MM:SS format 


timestamp 




%g 


Unix type timestamp 


time-taken 




%e 


Time taken (in milliseconds) to 
process the request 


rs-time-taken 






Total time taken (in milliseconds) 
to send the request and receive 
the response from the origin 
server 


x-bluecoat-end-time-wft 






End local time of the transaction 
represented as a windows file 
time 
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ELFF 
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Custom 


Description 


x-bluecoat-start-time-wft 






Start local time of the transaction 
represented as a windows file 
time 


x-bluecoat-end-time-mssql 






End local time of the transaction 
represented as a serial date time 


x-bluecoat-start-time-mssql 






Start local time of the transaction 
represented as a serial date time 


x-cookie-date 


cookie_date 




Current date in Cookie time 
format 


x-http-date 


http_date 




Current date in HTTP time 
format 


x-timestamp-unix 






Seconds since UNIX epoch (Jan 1, 
1970) (local time) 


x-timestamp-unix-utc 






Seconds since UNIX epoch (Jan 1, 
1970) (GMT/UTC) 




Category: url 


cs-host 




%v 


Hostname from the client's 
request URL. If URL rewrite 
policies are used, this field's value 
is derived from the 'log' URL 


cs-uri 


log_url 


%i 


The 'log' URL. 


cs-uri-address 


log_url.address 




IP address from the 'log' URL. 
DNS is used if URL uses a 
hostname. 


cs-uri-extension 


log_url.extension 




Document extension from the 
'log' URL. 


cs-uri-host 


log_url.host 




Hostname from the 'log' URL. 


cs-uri-hostname 


log_url.hostname 




Hostname from the 'log' URL. 
RDNS is used if the URL uses an 
IP address. 


cs-uri-path 


log_url.path 


%U 


Path from the 'log' URL. Does not 
include query. 


cs-uri-pathquery 


log_url.pathquery 




Path and query from the 'log' 
URL. 


cs-uri-port 


log_url.port 




Port from the 'log' URL. 


cs-uri-query 


log_url.query 


%Q 


Query from the 'log' URL. 
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CPL 


Custom 


Description 


cs-uri-scheme 


log_url.scheme 




Scheme from the 'log' URL. 


cs-uri-stem 






Stem from the 'log' URL. The 
stem includes everything up to 
the end of path, but does not 
include the query. 


c-uri 


url 




The original URL requested. 


c-uri-address 


url.address 




IP address from the original URL 
requested. DNS is used if the 
URL is expressed as a hostname. 


c-uri-cookie-domain 


url.cookie_domain 




The cookie domain of the original 
URL requested 


c-uri-extension 


url.extension 




Document extension from the 
original URL requested 


c-uri-host 


url.host 




Hostname from the original URL 
requested 


c-uri-hostname 


url.hostname 




Hostname from the original URL 
requested. RDNS is used if the 
URL is expressed as an IP address 


c-uri-path 


url.path 




Path of the original URL 
requested without query. 


c-uri-pathquery 


url.pathquery 




Path and query of the original 
URL requested 


c-uri-port 


url.port 




Port from the original URL 
requested 


c-uri-query 


url. query 




Query from the original URL 
requested 


c-uri-scheme 


url.scheme 




Scheme of the original URL 
requested 


c-uri-stem 






Stem of the original URL 
requested 


sr-uri 


server_url 




URL of the upstream request 


sr-uri-address 


server_url .address 




IP address from the URL used in 
the upstream request. DNS is 
used if the URL is expressed as a 
hostname. 


sr-uri-extension 


server_url.extension 




Document extension from the 
URL used in the upstream 
request 
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Custom 


Description 


sr-uri-host 


server_url.host 




Hostname from the URL used in 
the upstream request 


sr-uri-hostname 


server_url.hostname 




Hostname from the URL used in 
the upstream request. RDNS is 
used if the URL is expressed as an 
IP address. 


sr-uri-path 


server_url.path 




Path from the upstream request 
URL 


sr-uri-pathquery 


server_url.pathquery 




Path and query from the 
upstream request URL 


sr-uri-port 


server_url.port 




Port from the URL used in the 
upstream request. 


sr-uri-query 


server_url.query 




Query from the upstream request 
URL 


sr-uri-scheme 


server_url.scheme 




Scheme from the URL used in the 
upstream request 


sr-uri-stem 






Path from the upstream request 
URL 


s-uri 


cache_url 




The URL used for cache access 


s-uri-address 


cache_url. address 




IP address from the URL used for 
cache access. DNS is used if the 
URL is expressed as a hostname 


s-uri-extension 


cache_url.extension 




Document extension from the 
URL used for cache access 


s-uri-host 


cache_url.host 




Hostname from the URL used for 
cache access 


s-uri-hostname 


cache_url.hostname 




Hostname from the URL used for 
cache access. RDNS is used if the 
URL uses an IP address 


s-uri-path 


cache_url.path 




Path of the URL used for cache 
access 


s-uri-pathquery 


cache_url.pathquery 




Path and query of the URL used 
for cache access 


s-uri-port 


cache_url.port 




Port from the URL used for cache 
access 


s-uri-query 


cache_url.query 




Query string of the URL used for 
cache access 
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Custom 


Description 


s-uri-scheme 


cache_url.scheme 




Scheme from the URL used for 
cache access 


s-uri-stem 






Stem of the URL used for cache 
access 


x-cs(Referer)-uri 


request.header.Referer.url 




The URL from the Referer header. 


x-cs(Referer)-uri-address 


request.header.Referer.url. address 




IP address from the 'Referer' 
URL. DNS is used if URL uses a 
hostname. 


x-cs(Referer)-uri-extension 


request.header.Referer.url.extension 




Document extension from the 
'Referer' URL. 


x-cs(Referer)-uri-host 


request.header.Referer.url.host 




Hostname from the 'Referer' URL. 


x-cs(Referer)-uri-hostname 


request.header.Referer.url.hostname 




Hostname from the 'Referer' URL. 
RDNS is used if the URL uses an 
IP address. 


x-cs(Referer)-uri-path 


request.header.Referer.url.path 




Path from the 'Referer' URL. Does 
not include query. 


x-cs(Referer)-uri-pathquery 


request.header.Referer.url.pathquery 




Path and query from the 'Referer' 
URL. 


x-cs(Referer)-uri-port 


request.header.Referer.url.port 




Port from the 'Referer' URL. 


x-cs(Referer)-uri-query 


request.header.Referer.url. query 




Query from the 'Referer' URL. 


x-cs(Referer)-uri-scheme 


request.header.Referer.url.scheme 




Scheme from the 'Referer' URL. 


x-cs(Referer)-uri-stem 






Stem from the 'Referer' URL. The 
stem includes everything up to 
the end of path, but does not 
include the query. 


x-cs-raw-uri 


raw_url 




The 'raw' request URL. 


x-cs-raw-uri-host 


raw_url.host 




Hostname from the 'raw' URL. 


x-cs-raw-uri-port 


raw_url.port 




Port string from the 'raw' URL. 


x-cs-raw-uri-scheme 


raw_url.scheme 




Scheme string from the 'raw' 
URL. 


x-cs-raw-uri-path 


raw_url.path 




Path from the ’raw' request URL. 
Does not include query. 


x-cs-raw-uri-pathquery 


raw_url.pathquery 




Path and query from the 'raw' 
request URL. 


x-cs-raw-uri-query 


raw_url. query 




Query from the ’raw' request 
URL. 



1071 



Blue Coat Proxy SG Configuration and Management Guide 



Table B.6: Access Log Substitutions (Continued) 



ELFF 
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Custom 


Description 


x-cs-raw-uri-stem 






Stem from the 'raw' request URL. 
The stem includes everything up 
to the end of path, but does not 
include the query. 




Category: user 


cs-auth-group 


group 




One group that an authenticated 
user belongs to. If a user belongs 
to multiple groups, the group 
logged is determined by the 
Group Log Order configuration 
specified in VPM. If Group Log 
Order is not specified, an 
arbitrary group is logged. Note 
that only groups referenced by 
policy are considered. 


cs-auth-groups 


groups 




List of groups that an 
authenticated user belongs to. 
Note that only groups referenced 
by policy are included. 


cs-auth-type 






Client-side: authentication type 
(basic, ntlm, etc.) 


cs-realm 


realm 




Authentication realm that the 
user was challenged in. 


cs-user 




%u 


Qualified username for NTLM. 
Relative username for other 
protocols 


cs-userdn 


user 




Full username of a client 
authenticated to the proxy (fully 
distinguished) 


x-cs-user-authorization- 

name 


user.authorization_name 




Username used to authorize a 
client authenticated to the proxy 


cs-username 


user.name 




Relative username of a client 
authenticated to the proxy (i.e. 
not fully distinguished) 


sc-auth-status 






Client-side: Authorization status 


x-agent-sso-cookie 






The authentication agent single 
signon cookie 
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Custom 


Description 


x-cache-user 






Relative username of a client 
authenticated to the proxy (i.e. 
not fully distinguished) (same as 
cs-username) 


x-cs-auth-domain 


user, domain 




The domain of the authenticated 
user. 


x-cs-auth-form-action-url 






The URL to submit the 
authentication form to. 


x-cs-auth-form-domain- 

field 






The authentication form input 
field for the user's domain. 


x-cs-auth-request-id 






The bas64 encoded string 
containing the original request 
information during forms based 
authentication 


x-cs-username-or-ip 






Used to identify the user using 
either their authenticated proxy 
username or, if that is 
unavailable, their IP address. 


x-radius-splash-session-id 






Session ID made available 
through RADIUS when 
configured for session 
management 


x-radius-splash-usemame 






Username made available 
through RADIUS when 
configured for session 
management 


x-user-x509-issuer 


user.x509.issuer 




If the user was authenticated via 
an X.509 certificate, this is the 
issuer of the certificate as an 
RFC2253 DN 


x-user-x509-serial-number 


user.x509 . serialN umber 




If the user was authenticated via 
an X.509 certificate, this is the 
serial number from the certificate 
as a hexadecimal number. 


x-user-x509-subject 


user.x509. subject 




If the user was authenticated via 
an X.509 certificate, this is the 
subject of the certificate as an 
RFC2253 DN 


x-auth-challenge-string 






The authentication challenge to 
display to the user. 
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ELFF 


CPL 


Custom 


Description 


x-auth-private-challenge- 

state 






The private state required to 
manage an authentication 
challenge 




Category: ci_request_header 


cs(Accept) 


request.header. Accept 




Request header: Accept 


cs(Accept)-length 


request.header.Accept.length 




Length of HTTP request header: 
Accept 


cs(Accept)-count 


request.header. Accept.count 




Number of HTTP request header: 
Accept 


cs(Accept-Charset) 


request.header.Accept-Charset 




Request header: Accept-Charset 


cs(Accept-Charset)-length 


request.header. Accept-Charset.length 




Length of HTTP request header: 
Accept-Charset 


cs(Accept-Charset)-count 


request.header. Accept-Charset.count 




Number of HTTP request header: 
Accept-Charset 


cs(Accept-Encoding) 


request.header. Accept-Encoding 




Request header: Accept-Encoding 


cs(Accept-Encoding)-length 


request.header. Accept-Encoding.length 




Length of HTTP request header: 
Accept-Encoding 


cs(Accept-Encoding)-count 


request.header. Accept-Encoding.count 




Number of HTTP request header: 
Accept-Encoding 


cs(Accept-Language) 


request.header. Accept-Language 




Request header: 
Accept-Language 


cs(Accept-Language)- 

length 


request.header. Accept-Language.length 




Length of HTTP request header: 
Accept-Language 


cs(Accept-Language)-count 


request.header. Accept-Language.count 




Number of HTTP request header: 
Accept-Language 


cs(Accept-Ranges) 


request.header. Accept-Ranges 




Request header: Accept-Ranges 


cs(Accept-Ranges)-length 


request.header. Accept-Ranges.length 




Length of HTTP request header: 
Accept-Ranges 


cs(Accept-Ranges)-count 


request.header. Accept-Ranges.count 




Number of HTTP request header: 
Accept-Ranges 


cs(Age) 


request.header. Age 




Request header: Age 


cs(Age)-length 


request.header. Age.length 




Length of HTTP request header: 
Age 
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ELFF 


CPL 


Custom 


Description 


cs(Age)-count 


request.header.Age.count 




Number of HTTP request header: 
Age 


cs(Allow) 


request.header. Allow 




Request header: Allow 


cs(Allow)-length 


request.header.Allow.length 




Length of HTTP request header: 
Allow 


cs(Allow)-count 


request.header.Allow.count 




Number of HTTP request header: 
Allow 


cs(Authentication-Info) 


request.header.Authentication-Info 




Request header: 
Authentication-Info 


cs(Authentication-Info)- 

length 


request.header. Authentication-Info, 
length 




Length of HTTP request header: 
Authentication-Info 


cs(Authentication-Info)- 

count 


request.header. Authentication-Info. cou 
nt 




Number of HTTP request header: 
Authentication-Info 


cs(Authorization) 


request.header. Authorization 




Request header: Authorization 


cs(Authorization)-length 


request.header. Authorization.length 




Length of HTTP request header: 
Authorization 


cs(Authorization)-count 


request.header. Authorization.count 




Number of HTTP request header: 
Authorization 


cs(Cache-Control) 


request.header.Cache-Control 




Request header: Cache-Control 


cs(Cache-Control)-length 


request.header.Cache-Control.length 




Length of HTTP request header: 
Cache-Control 


cs(Cache-Control)-count 


request.header.Cache-Control.count 




Number of HTTP request header: 
Cache-Control 


cs(Client-IP) 


request.header.Client-IP 




Request header: Client-IP 


cs(Client-IP)-length 


request.header.Client-IP.length 




Length of HTTP request header: 
Client-IP 


cs(Client-IP)-count 


request.header. Client-IP.count 




Number of HTTP request header: 
Client-IP 


cs(Connection) 


request.header.Connection 




Request header: Connection 


cs(Connection)-length 


request.header.Connection.length 




Length of HTTP request header: 
Connection 


cs(Connection)-count 


request.header.Connection.count 




Number of HTTP request header: 
Connection 


cs(Content-Encoding) 


request.header.Content-Encoding 




Request header: 
Content-Encoding 
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ELFF 


CPL 


Custom 


Description 


cs(Content-Encoding)- 

length 


request.header.Content-Encoding. 

length 




Length of HTTP request header: 
Content-Encoding 


cs(Content-Encoding)- 

count 


request.header.Content-Encoding.count 




Number of HTTP request header: 
Content-Encoding 


cs(Content-Language) 


request.header.Content-Language 




Request header: 
Content-Language 


cs(Content-Language)- 

length 


request.header.Content-Language. 

length 




Length of HTTP request header: 
Content-Language 


cs(Content-Language)- 

count 


request.header.Content-Language.count 




Number of HTTP request header: 
Content-Language 


cs(Content-Length) 


request.header.Content-Length 




Request header: Content-Length 


cs(Content-Length)-length 


request.header.Content-Length.length 




Length of HTTP request header: 
Content-Length 


cs(Content-Length)-count 


request.header.Content-Length.count 




Number of HTTP request header: 
Content-Length 


cs(Content-Location) 


request.header.Content-Location 




Request header: 
Content-Location 


cs(Content-Location)-length 


request.header.Content-Location.length 




Length of HTTP request header: 
Content-Location 


cs(Content-Location)-count 


request.header.Content-Location.count 




Number of HTTP request header: 
Content-Location 


cs(Content-MD5) 


request.header.Content-MD5 




Request header: Content-MD5 


cs(Content-MD5)-length 


request.header.Content-MD5.1ength 




Length of HTTP request header: 
Content-MD5 


cs(Content-MD5)-count 


request.header.Content-MD5. count 




Number of HTTP request header: 
Content-MD5 


cs(Content-Range) 


request.header.Content-Range 




Request header: Content-Range 


cs(Content-Range)-length 


request.header.Content-Range.length 




Length of HTTP request header: 
Content-Range 


cs(Content-Range)-count 


request.header.Content-Range.count 




Number of HTTP request header: 
Content-Range 


cs(Content-Type) 


request.header.Content-Type 




Request header: Content-Type 


cs(Content-Type)-length 


request.header.Content-Type. length 




Length of HTTP request header: 
Content-Type 
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ELFF 


CPL 


Custom 


Description 


cs(Content-Type)-count 


request.header.Content-Type.count 




Number of HTTP request header: 
Content-Type 


cs(Cookie) 


request.header.Cookie 


%C 


Request header: Cookie 


cs(Cookie)-length 


request.header.Cookie.length 




Length of HTTP request header: 
Cookie 


cs(Cookie)-count 


request.header.Cookie.count 




Number of HTTP request header: 
Cookie 


cs(Cookie2) 


request.header.Cookie2 




Request header: Cookie2 


cs(Cookie2)-length 


request.header.Cookie2.1ength 




Length of HTTP request header: 
Cookie2 


cs(Cookie2)-count 


request.header.Cookie2.count 




Number of HTTP request header: 
Cookie2 


cs(Date) 


request.header.Date 




Request header: Date 


cs(Date)-length 


request.header.Date.length 




Length of HTTP request header: 
Date 


cs(Date)-count 


request.header.Date.count 




Number of HTTP request header: 
Date 


cs(Etag) 


request.header.Etag 




Request header: Etag 


cs(Etag)-length 


request.header.Etag.length 




Length of HTTP request header: 
Etag 


cs(Etag)-count 


request.header.Etag.count 




Number of HTTP request header: 
Etag 


cs(Expect) 


request.header.Expect 




Request header: Expect 


cs(Expect)-length 


request.header.Expect.length 




Length of HTTP request header: 
Expect 


cs(Expect)-count 


request.header.Expect.count 




Number of HTTP request header: 
Expect 


cs(Expires) 


request.header.Expires 




Request header: Expires 


cs(Expires)-length 


request.header.Expires.length 




Length of HTTP request header: 
Expires 


cs(Expires)-count 


request.header.Expires. count 




Number of HTTP request header: 
Expires 


cs(From) 


request.header.From 




Request header: From 


cs(From)-length 


request.header.From.length 




Length of HTTP request header: 
From 
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ELFF 


CPL 


Custom 


Description 


cs(From)-count 


request.header.From.count 




Number of HTTP request header: 
From 


cs(Front-End-HTTPS) 


request.header.Front-End-HTTPS 




Request header: 
Front-End-HTTPS 


cs(Front-End-HTTPS)- 

length 


request.header.Front-End-HTTPS. 

length 




Length of HTTP request header: 
Front-End-HTTPS 


cs(Front-End-HTTPS)-count 


request.header.Front-End-HTTPS. count 




Number of HTTP request header: 
Front-End-HTTPS 


cs(Host) 


request.header.Host 




Request header: Host 


cs(Host)-length 


request.header.Host.length 




Length of HTTP request header: 
Host 


cs(Host)-count 


request.header.Host.count 




Number of HTTP request header: 
Host 


cs(If-Match) 


request.header.If-Match 




Request header: If-Match 


cs(If-Match)-length 


request.header.If-Match.length 




Length of HTTP request header: 
If-Match 


cs(If-Match)-count 


request.header.If-Match.count 




Number of HTTP request header: 
If-Match 


cs(If-Modified-Since) 


request.header.If-Modified-Since 




Request header: 
If-Modified-Since 


cs(If-Modified-Since)-length 


request.header.If-Modified-Since.length 




Length of HTTP request header: 
If-Modified-Since 


cs(If-Modified-Since)-count 


request.header.If-Modified-Since. count 




Number of HTTP request header: 
If-Modified-Since 


cs(If-None-Match) 


request.header.If-None-Match 




Request header: If-None-Match 


cs(If-None-Match)-length 


request.header.If-None-Match.length 




Length of HTTP request header: 
If-None-Match 


cs(If-None-Match)-count 


request.header.If-None-Match.count 




Number of HTTP request header: 
If-None-Match 


cs(If-Range) 


request.header.If-Range 




Request header: If-Range 


cs(If-Range)-length 


request.header.If-Range.length 




Length of HTTP request header: 
If-Range 


cs(If-Range)-count 


request.header.If-Range.count 




Number of HTTP request header: 
If-Range 


cs(If-Unmodified-Since) 


request.header.If-Unmodified-Since 




Request header: 
If-Unmodified-Since 



1078 



Appendix B: Access Log Formats 



Table B.6: Access Log Substitutions (Continued) 



ELFF 


CPL 


Custom 


Description 


cs(If-Unmodified-Since)- 

length 


request.header.If-Unmodified-Since. 

length 




Length of HTTP request header: 
If-Unmodified-Since 


cs(If-Unmodified-Since)- 

count 


request.header.If-Unmodified-Since. 

count 




Number of HTTP request header: 
If-Unmodified-Since 


cs(Last-Modified) 


request.header.Last-Modified 




Request header: Last-Modified 


cs(Last-Modified)-length 


request.header.Last-Modified.length 




Length of HTTP request header: 
Last-Modified 


cs(Last-Modified)-count 


request.header.Last-Modified.count 




Number of HTTP request header: 
Last-Modified 


cs(Location) 


request.header.Location 




Request header: Location 


cs(Location)-length 


request.header.Location.length 




Length of HTTP request header: 
Location 


cs(Location)-count 


request.header.Location.count 




Number of HTTP request header: 
Location 


cs(Max-Forwards) 


request.header.Max-Forwards 




Request header: Max-Forwards 


cs(Max-Forwards)-length 


request.header.Max-Forwards. length 




Length of HTTP request header: 
Max-Forwards 


cs(Max-Forwards)-count 


request.header.Max-Forwards.count 




Number of HTTP request header: 
Max-Forwards 


cs(Meter) 


request.header.Meter 




Request header: Meter 


cs(Meter)-length 


request.header.Meter.length 




Length of HTTP request header: 
Meter 


cs(Meter)-count 


request.header.Meter.count 




Number of HTTP request header: 
Meter 


cs(P3P) 


request.header.P3P 




Request header: P3P 


cs(P3P)-length 


request.header.P3P.length 




Length of HTTP request header: 
P3P 


cs(P3P)-count 


request.header.P3P.count 




Number of HTTP request header: 
P3P 


cs(Pragma) 


request.header.Pragma 




Request header: Pragma 


cs(Pragma)-length 


request.header.Pragma.length 




Length of HTTP request header: 
Pragma 


cs(Pragma)-count 


request.header.Pragma. count 




Number of HTTP request header: 
Pragma 
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ELFF 


CPL 


Custom 


Description 


cs(Proxy- Authenticate) 


request.header.Proxy- Authenticate 




Request header: 
Proxy- Authenticate 


cs(Proxy-Authenticate)- 

length 


request.header.Proxy- Authenticate, 
length 




Length of HTTP request header: 
Proxy- Authenticate 


cs(Proxy-Authenticate)- 

count 


request.header.Proxy- Authenticate, 
count 




Number of HTTP request header: 
Proxy- Authenticate 


cs(Proxy- Authorization) 


request.header.Proxy- Authorization 




Request header: 
Proxy- Authorization 


cs(Proxy-Authorization)- 

length 


request.header.Proxy- Authorization, 
length 




Length of HTTP request header: 
Proxy- Authorization 


cs(Proxy-Authorization)- 

count 


request.header.Proxy- Authorization, 
count 




Number of HTTP request header: 
Proxy- Authorization 


cs(Proxy-Connection) 


request.header.Proxy-Connection 




Request header: 
Proxy-Connection 


cs(Proxy-Connection)- 

length 


request.header.Proxy-Connection. 

length 




Length of HTTP request header: 
Proxy-Connection 


cs(Proxy-Connection)-count 


request.header.Proxy-Connection.count 




Number of HTTP request header: 
Proxy-Connection 


cs(Range) 


request.header.Range 




Request header: Range 


cs(Range)-length 


request.header.Range.length 




Length of HTTP request header: 
Range 


cs(Range)-count 


request.header.Range.count 




Number of HTTP request header: 
Range 


cs(Referer) 


request.header.Referer 


%R 


Request header: Referer 


cs(Referer)-length 


request.header.Referer.length 




Length of HTTP request header: 
Referer 


cs(Referer)-count 


request.header.Referer.count 




Number of HTTP request header: 
Referer 


cs(Refresh) 


request.header.Refresh 




Request header: Refresh 


cs(Refresh)-length 


request.header.Refresh.length 




Length of HTTP request header: 
Refresh 


cs(Refresh)-count 


request.header.Refresh.count 




Number of HTTP request header: 
Refresh 


cs(Retry-After) 


request.header.Retry- After 




Request header: Retry- After 


cs(Retry-After)-length 


request.header.Retry-After.length 




Length of HTTP request header: 
Retry-After 



1080 



Appendix B: Access Log Formats 



Table B.6: Access Log Substitutions (Continued) 



ELFF 


CPL 


Custom 


Description 


cs(Retry-After)-count 


request.header.Retry-After.count 




Number of HTTP request header: 
Retry-After 


cs(Server) 


request.header.Server 




Request header: Server 


cs (Server) -length 


request.header.Server.length 




Length of HTTP request header: 
Server 


cs(Server)-count 


request.header.Server.count 




Number of HTTP request header: 
Server 


cs(Set-Cookie) 


request.header.Set-Cookie 




Request header: Set-Cookie 


cs(Set-Cookie)-length 


request.header.Set-Cookie.length 




Length of HTTP request header: 
Set-Cookie 


cs(Set-Cookie)-count 


request.header.Set-Cookie.count 




Number of HTTP request header: 
Set-Cookie 


cs(Set-Cookie2) 


request.header.Set-Cookie2 




Request header: Set-Cookie2 


cs(Set-Cookie2)-length 


request.header.Set-Cookie2.1ength 




Length of HTTP request header: 
Set-Cookie2 


cs(Set-Cookie2)-count 


request.header.Set-Cookie2.count 




Number of HTTP request header: 
Set-Cookie2 


cs(TE) 


request.header.TE 




Request header: TE 


cs(TE)-length 


request.header.TE.length 




Length of HTTP request header: 
TE 


cs(TE)-count 


request.header.TE. count 




Number of HTTP request header: 
TE 


cs(Trailer) 


request.header. Trailer 




Request header: Trailer 


cs(Trailer)-length 


request.header.Trailer.length 




Length of HTTP request header: 
Trailer 


cs(Trailer)-count 


request.header. Trailer.count 




Number of HTTP request header: 
Trailer 


cs(Transfer-Encoding) 


request.header. Transfer-Encoding 




Request header: 
Transfer-Encoding 


cs(Transfer-Encoding)- 

length 


request.header. Transfer-Encoding, 
length 




Length of HTTP request header: 
Transfer-Encoding 


cs(Transfer-Encoding)- 

count 


request.header. Transfer-Encoding.count 




Number of HTTP request header: 
Transfer-Encoding 


cs(Upgrade) 


request.header.Upgrade 




Request header: Upgrade 
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ELFF 


CPL 


Custom 


Description 


cs(Upgrade)-length 


request.header.Upgrade.length 




Length of HTTP request header: 
Upgrade 


cs(Upgrade)-count 


request.header.Upgrade.count 




Number of HTTP request header: 
Upgrade 


cs(User-Agent) 


request.header.User- Agent 


%A 


Request header: User-Agent 


cs (U ser- Agent) -length 


request.header.User-Agent.length 




Length of HTTP request header: 
User-Agent 


cs(User-Agent)-count 


request.header.User- Agent.count 




Number of HTTP request header: 
User-Agent 


cs(Vary) 


request.header.Vary 




Request header: Vary 


cs(Vary)-length 


request.header.Vary.length 




Length of HTTP request header: 
Vary 


cs(Vary)-count 


request.header.Vary.count 




Number of HTTP request header: 
Vary 


cs(Via) 


request.header.Via 




Request header: Via 


cs(Via)-length 


request.header.Via.length 




Length of HTTP request header: 
Via 


cs(Via)-count 


request.header.Via.count 




Number of HTTP request header: 
Via 


cs(WWW- Authenticate) 


request.header. WWW- Authenticate 




Request header: 
WWW- Authenticate 


cs(WWW-Authenticate)- 

length 


request.header. WWW- Authenticate, 
length 




Length of HTTP request header: 
WWW- Authenticate 


cs(WWW-Authenticate)- 

count 


request.header. WWW- Authenticate, 
count 




Number of HTTP request header: 
WWW- Authenticate 


cs(Warning) 


request.header. Warning 




Request header: Warning 


cs(Warning)-length 


request.header. Warning.length 




Length of HTTP request header: 
Warning 


cs(Warning)-count 


request.header. Warning.count 




Number of HTTP request header: 
Warning 


cs(X-BlueCoat-Error) 


request.header.X-BlueCoat-Error 




Request header: 
X-BlueCoat-Error 


cs(X-BlueCoat-Error)-length 


request.header.X-BlueCoat-Error.length 




Length of HTTP request header: 
X-BlueCoat-Error 


cs(X-BlueCoat-Error)-count 


request.header.X-BlueCoat-Error.count 




Number of HTTP request header: 
X-BlueCoat-Error 
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ELFF 


CPL 


Custom 


Description 


cs(X-BlueCoat-MC-Client- 

IP) 


request.header.X-BlueCoat-MC-Client- 

IP 




Request header: 
X-BlueCoat-MC-Client-Ip 


cs(X-BlueCoat-MC-Client- 

Ip)-length 


request.header.X-BlueCoat-MC-Client- 
Ip. length 




Length of HTTP request header: 
X-BlueCoat-MC-Client-Ip 


cs(X-BlueCoat-MC-Client- 

Ip)-count 


request.header.X-BlueCoat-MC-Client- 
Ip. count 




Number of HTTP request header: 
X-BlueCoat-MC-Client-Ip 


cs(X-BlueCoat-Via) 


request.header.X-BlueCoat-Via 




Request header: X-BlueCoat-Via 


cs(X-BlueCoat-Via)-length 


request.header.X-BlueCoat-Via.length 




Length of HTTP request header: 
X-BlueCoat-Via 


cs(X-BlueCoat-Via)-count 


request.header.X-BlueCoat-Via.count 




Number of HTTP request header: 
X-BlueCoat-Via 


cs(X-Forwarded-For) 


request.header.X-Forwarded-For 


%X 


Request header: 
X-Forwarded-For 


cs(X-Forwarded-For)-length 


request.header.X-Forwarded-For.length 




Length of HTTP request header: 
X-Forwarded-For 


cs(X-Forwarded-For)-count 


request.header.X-Forwarded-For.count 




Number of HTTP request header: 
X-Forwarded-For 




Category: si_response_header 


rs(Accept) 


response.header. Accept 




Response header: Accept 


rs(Accept-Charset) 


response.header.Accept-Charset 




Response header: Accept-Charset 


rs(Accept-Encoding) 


response.header. Accept-Encoding 




Response header: 
Accept-Encoding 


rs(Accept-Language) 


response.header. Accept-Language 




Response header: 
Accept-Language 


rs(Accept-Ranges) 


response.header. Accept-Ranges 




Response header: Accept-Ranges 


rs(Age) 


response.header. Age 




Response header: Age 


rs (Allow) 


response.header. Allow 




Response header: Allow 


rs(Authentication-Info) 


response.header. Authentication-Info 




Response header: 
Authentication-Info 


rs(Authorization) 


response.header. Authorization 




Response header: Authorization 


rs(Cache-Control) 


response.header.Cache-Control 




Response header: Cache-Control 


rs(Client-IP) 


response.header.Client-IP 




Response header: Client-IP 


rs(Connection) 


response.header.Connection 




Response header: Connection 
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ELFF 


CPL 


Custom 


Description 


rs(Content-Encoding) 


response.header.Content-Encoding 




Response header: 
Content-Encoding 


rs(Content-Language) 


response.header.Content-Language 




Response header: 
Content-Language 


rs(Content-Length) 


response.header.Content-Length 




Response header: 
Content-Length 


rs(Content-Location) 


response.header.Content-Location 




Response header: 
Content-Location 


rs(Content-MD5) 


response.header.Content-MD5 




Response header: Content-MD5 


rs(Content-Range) 


response.header.Content-Range 




Response header: Content-Range 


rs(Content-Type) 


response.header.Content-Type 


%c 


Response header: Content-Type 


rs(Cookie) 


response.header.Cookie 




Response header: Cookie 


rs(Cookie2) 


response.header.Cookie2 




Response header: Cookie2 


rs(Date) 


response.header.Date 




Response header: Date 


rs(Etag) 


response.header.Etag 




Response header: Etag 


rs(Expect) 


response.header.Expect 




Response header: Expect 


rs(Expires) 


response.header.Expires 




Response header: Expires 


rs(From) 


response.header.From 




Response header: From 


rs(Front-End-HTTPS) 


response.header.Front-End-HTTPS 




Response header: 
Front-End-HTTPS 


rs(Host) 


response.header.Host 




Response header: Host 


rs(If-Match) 


response.header.If-Match 




Response header: If-Match 


rs(If-Modified-Since) 


response.header.If-Modified-Since 




Response header: 
If-Modified-Since 


rs (If-N one-Match) 


response.header.If-None-Match 




Response header: If-None-Match 


rs(If-Range) 


response.header.If-Range 




Response header: If-Range 


rs(If-Unmodified-Since) 


response.header.If-Unmodified-Since 




Response header: 
If-Unmodified-Since 


rs(Last-Modified) 


response.header.Last-Modified 




Response header: Last-Modified 


rs(Location) 


response.header.Location 




Response header: Location 


rs(Max-Forwards) 


response.header.Max-Forwards 




Response header: Max-Forwards 


rs(Meter) 


response.header.Meter 




Response header: Meter 
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ELFF 


CPL 


Custom 


Description 


rs(P3P) 


response.header.P3P 




Response header: P3P 


rs(Pragma) 


response.header.Pragma 




Response header: Pragma 


rs(Proxy- Authenticate) 


response.header.Proxy- Authenticate 




Response header: 
Proxy- Authenticate 


rs(Proxy- Authorization) 


response.header.Proxy- Authorization 




Response header: 
Proxy- Authorization 


rs(Proxy-Connection) 


response.header.Proxy-Connection 




Response header: 
Proxy-Connection 


rs(Range) 


response.header.Range 




Response header: Range 


rs(Referer) 


response.header.Referer 




Response header: Referer 


rs(Refresh) 


response.header.Refresh 




Response header: Refresh 


rs(Retry-After) 


response.header.Retry- After 




Response header: Retry- After 


rs (Server) 


response.header.Server 




Response header: Server 


rs(Set-Cookie) 


response.header.Set-Cookie 




Response header: Set-Cookie 


rs(Set-Cookie2) 


response.header.Set-Cookie2 




Response header: Set-Cookie2 


rs(TE) 


response.header.TE 




Response header: TE 


rs(Trailer) 


response.header. Trailer 




Response header: Trailer 


rs(Transfer-Encoding) 


response.header. Transfer-Encoding 




Response header: 
Transfer-Encoding 


rs(Upgrade) 


response.header.Upgrade 




Response header: Upgrade 


rs(User-Agent) 


response.header.User- Agent 




Response header: User- Agent 


rs(Vary) 


response.header. Vary 




Response header: Vary 


rs(Via) 


response.header. Via 




Response header: Via 


rs(WWW- Authenticate) 


response.header. WWW- Authenticate 




Response header: 
WWW- Authenticate 


rs(Warning) 


response.header. Warning 




Response header: Warning 


rs(X-BlueCoat-Error) 


response.header.X-BlueCoat-Error 




Response header: 
X-BlueCoat-Error 


rs(X-BlueCoat-MC-Client-I 

P) 


response.header.X-BlueCoat-MC-Client 

-Ip 




Response header: 
X-BlueCoat-MC-Client-Ip 


rs(X-BlueCoat-Via) 


response.header.X-BlueCoat-Via 




Response header: X-BlueCoat-Via 
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Table B.6: Access Log Substitutions (Continued) 



ELFF 


CPL 


Custom 


Description 


rs(X-Forwarded-For) 


response.header.X-Forwarded-For 




Response header: 
X-Forwarded-For 
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This appendix discusses how to configure a Blue Coat Systems ProxySG to participate in a Web Cache 
Communication Protocol (WCCP) scheme, when a WCCP-capable router collaborates with a set of 
WCCP-configured ProxySG Appliances to service requests. If you are already familiar with WCCP 
version 2 and want to get your router and ProxySG up and running right away, see the "Quick Start" 
on page 1089. 



Important: Bridge interfaces cannot be used in WCCP configurations. If the configuration 

includes bridge interfaces, you will receive the following error if you attempt to load 
the WCCP configuration file: Interface 0:0 is member of a bridge 



Overview 

WCCP is a Cisco®-developed protocol that allows you to establish redirection of the traffic that flows 
through routers. 

The main benefits of using WCCP are: 

□ Scalability. With no reconfiguration overhead, redirected traffic can be automatically distributed 
to up to 32 ProxySG Appliances. 

□ Redirection safeguards. If no ProxySG Appliances are available, redirection stops and the router 
forwards traffic to the original destination address. 

WCCP has two versions, version 1 and version 2, both of which are supported by Blue Coat. However, 
only one protocol version can be active on the ProxySG at a time. The active WCCP protocol set up in 
the ProxySG configuration must match the version running on the WCCP router. 

Using WCCP and Transparent Redirection 

A WCCP-capable router operates in conjunction with the ProxySG Appliances to transparently 
redirect traffic to a set of caches that participate in the specified WCCP protocol. IP packets are 
redirected based on fields within each packet. For instance, WCCP version 1 only redirects destination 
TCP port 80 (default HTTP traffic) IP packets. WCCP version 2 allows you to redirect traffic from other 
ports and protocols. 

Load balancing is achieved with either a redirection hash table or a mask assignment table that 
determines which ProxySG will receive the redirected packet. 

WCCP Version 1 

In WCCP version 1, the WCCP-configured home router transparently redirects TCP port 80 packets to 
a maximum of 32 ProxySG Appliances. (A ProxySG is seen as a cache in WCCP protocol.) 
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One of the caches participating in the WCCP service group is automatically elected to configure the 
home router's redirection tables. This way, caches can be transparently added and removed from the 
WCCP service group without requiring operator intervention. WCCP version 1 supports only a single 
service group. 

"" on page 1088 illustrates a typical WCCP version 1 implementation. 

Each applicable client IP packet received by the home router is transparently redirected to a cache. A 
ProxySG from the group is selected to define the home router's redirection hash table for all caches. 
All caches periodically communicate with the home router to verify WCCP protocol synchronization 
and ProxySG availability within the service group. In return, the home router responds to each cache 
with information as to which ProxySG Appliances are available in the service group. 



i 

Home 
Router 1 




1 Configuration 



The following are WCCP version 1 caveats: 

□ The home router IP must be configured on all participating interfaces and must match the home 
router address configured on the ProxySG. 

□ The adapter connected to the ProxySG must be Ethernet or Fast Ethernet. 

□ For Cisco routers using WCCP version 1, minimum IOS releases are 11.1(18)CA and 11.2(13)P. 
Note that releases prior to IOS 12.0(3)T only support WCCP version 1. Ensure that you are using 
the correct IOS software for the router and that the ProxySG configuration protocol version 
number and router protocol version number match. 



For more information on WCCP Version 1, refer to the Cisco Web site. The rest of this appendix 
discusses WCCP version 2 only. 



WCCP Version 2 

For Cisco routers using WCCP version 2, minimum IOS releases are 12.0(3)T and 12.0(4). Release 
12.0(5) and later releases support WCCP versions 1 and 2. Ensure that you use the correct IOS 
software for the router and that you have a match between the ProxySG configuration WCCP version 
number and router protocol version number. 
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WCCP version 2 protocol offers the same capabilities as version 1, along with increased protocol 
security and multicast protocol broadcasts. Version 2 multicasting allows caches and routers to 
discover each other through a common multicast service group and matching passwords. In addition, 
up to 32 WCCP-capable routers can transparently redirect traffic to a set of up to 32 ProxySG 
Appliances. Version 2 WCCP-capable routers are capable of redirecting IP traffic to a set of ProxySG 
Appliances based on various fields within those packets. 

Version 2 allows routers and caches to participate in multiple, simultaneous service groups. Routers 
can transparently redirect IP packets based on their formats. For example, one service group could 
redirect HTTP traffic and another could redirect FTP traffic. 



Note: Blue Coat recommends that WCCP-compliant caches from different vendors be kept 

separate and that only one vendor's routers be used in a service group. 



One of the caches participating in the WCCP service group is automatically elected to configure the 
home router's redirection tables. This way, caches can be transparently added and removed from the 
WCCP service group without requiring operator intervention. WCCP version 2 supports multiple 
service groups. 

Figure C-2, below, illustrates a WCCP version 2 implementation using multiple routers and ProxySG 
Appliances. In this scenario, routers 1 through n and caches 1 through m participate in the same 
service group. As in version 1, an appliance from the group is selected to define the redirection hash or 
mask assignment table in all routers for all caches. All caches periodically communicate with all 
routers to verify WCCP protocol synchronization and ProxySG and router availability within the 
service group. In return, each router responds to caches with information as to what caches and 
discovered routers are available in the service group. 

i \ 

Router 1 • ■ ■ Router n 



AA 



ProxySG 


ProxySG 




ProxySG 


1 


2 




3 



Figure C-2: A Version 2 Configuration Using Packet Redirection to Multiple Routers and Caches 

Quick Start 

Two tasks must be completed to get WCCP running: configuring the router and configuring the 
ProxySG. If you have a standard router and ProxySG configuration, use the Quick Start below. 
Otherwise, begin with the instructions in the procedure "To Do Initial Router Configuration”, below, 
and "To Create a ProxySG WCCP Configuration File and Enable WCCP" on page 1090. 
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If you require a more complicated configuration, start with "Configuring a WCCP Version 2 Service on 
the Router”. 

To Do Initial Router Configuration 

1. From the router (conf ig) mode, tell WCCP which service group you want use. The Web-cache 
service group redirects port 80 (HTTP) traffic only. 

Router (conf ig) #ip weep web-cache 

2. Enter the (config-if) submode by telling WCCP which IP address to use. 

Router (conf ig) #int interface 

where interface is the adapter interface with an IP address. The prompt changes to 
configuration interface submode. 

3. Enable packet redirection on an outbound (Internet facing) interface. 

Router (conf ig-if) # ip weep web-cache redirect out 

4. Prevent packets received on an adapter interface from being checked for redirection and allow the 
use of Blue Coat bypass lists. 

Router (conf ig-if ) # ip weep redirect exclude in 

For more information on WCCP router configuration, see "Configuring a WCCP Version 2 Service on 
the Router” on page 1090. 

To Create a ProxySG WCCP Configuration File and Enable WCCP 

1. Create a WCCP configuration file through either the ProxySG's CLI inline commands or through 
a text editor. Make sure that the home router you enter here is the home router that was named in 
the router's configuration. If you do have a mismatch, you must correct it before continuing. See 
"Identifying a Home Router/Router ID Mismatch" on page 1112. 

For more information on creating a configuration file, see "Creating a ProxySG WCCP 
Configuration File" on page 1097. 

If you used the inline commands, you have completed WCCP configuration for both the router 
and the ProxySG and you have enabled WCCP on the ProxySG. No further steps are needed. 

2. If you used a text editor, copy the file to an HTTP server accessible to the ProxySG. 

3. Enable WCCP and download the configuration file to the ProxySG. 

SGOS# (config) weep enable 

SGOS# (config) weep path http://205.66.255.10/files/wccp.txt 
SGOS# (config) load weep- settings 

Configuring a WCCP Version 2 Service on the Router 

Configuring a router requires that you work with two different types of configuration commands: 

□ Creating a service group (which uses global settings). 

□ Configuring the Internet-Connected Interface (which uses interface settings). 

Define service group settings before defining adapter interface settings. 
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Setting up a Service Group 

Services are of two types: 

□ Well known services (web-cache for port 80 — HTTP — redirection) 

The web- cache service group is supported by both Cisco and Blue Coat. 

□ Dynamic services (which can be used for other services, such as FTP, RTSP redirection, and reverse 
proxy). 

Dynamic service uses identifiers ranging from 0-99 to name the service group. 

WCCP global settings allow you to name the service group and then define the characteristics for that 
service group. Even if you use the pre-defined Web-cache service group, you should: 

□ configure a multicast group address 

□ create and identify a redirection access list and associate it with a service group 

□ create and identify a cache bypass list and associate it with a service group 

□ create password authentication for messages sent by the service group to the router 

Syntax for configuring a service group (global settings): 

ip weep {web-cache | service -number} [group -address groupaddress ] 

[redirect-list access-list] [group-list access-list] [password password] 



where: 



web-cache 


Enables port 80 (HTTP) service. 


service -number 


The identification number of the cache service group being controlled by the 
router. Services are identified using a value from 0 to 99. The reverse-proxy 
service is indicated using the value 99, although any value can be used for 
reverse proxy. 


group- address 
groupaddress 


(Optional) If no redirect list is defined (the default), all traffic is redirected. The 
group address option directs the router to use a specified multicast IP address 
to coalesce the "I See You" responses to the "Here I Am" messages that it has 
received on this address. The group -address argument requires a multicast 
address used by the router to determine which cache engine receives redirected 
messages. The response is sent to the group address, as well. If no group 
address is defined (the default), all "Here I Am" messages are responded to 
with a unicast reply. 


redirect-list 

access-list 


(Optional) Directs the router to use an access list to control traffic redirected to 
the defined service group. The access-list parameter specifies either a number 
from 1 to 99 identifying a predefined standard or extended access list number, 
or a name (up to 64 characters long) identifying an existing standard or 
extended access list. The access list itself specifies which traffic can be 
redirected. 
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group-list 

access-list 


(Optional) If no group list is defined (the default), all caches might participate in 
the service group. 

The group -list option directs the router to use an access list to determine 
which caches are allowed to participate in the service group. The access-list 
parameter specifies either a number from 1 to 99 identifying a predefined 
standard or extended access list number or a name (up to 64 characters long) 
identifying an existing standard or extended access list. The access list itself 
specifies which caches are permitted to participate in the service group. 


password 

password 


(Optional) By default, password authentication is not configured and 
authentication is disabled. 

The password option increases authentication security to messages received 
from the service group specified by the service-number. Messages that do not 
pass authentication are discarded. The password can be up to eight characters 
long. 

If you specify a password in the router configuration, you must also configure 
the same password separately on each cache. 



Naming a Service Group and Enabling WCCP 

WCCP version 2 is enabled when you name a WCCP service group. (Version 1 requires a specific 
enable command.) The service group can already exist, such as web-cache, or it could be a new 
group, such as 3 6. 

To Name a Service Group and Enable WCCP 

From the router (config) mode, enter the following command: 

Router# (config) ip weep web-cache 

-or- 

Router# (config) ip weep 36 

Configuring a Global Multicast Group Address 

Benefits of using a multicast address include reduced WCCP protocol traffic and the ability to easily 
add and remove caches and routers from a service group without having to reconfigure all service 
group members. Multicast addresses fall within the range of 224.0.0.0 to 239.255.255.255. 

Use the following syntax to configure a global multicast group address for multicast cache discovery, 
ip weep {web-cache | service -number} [group -address group_address\ 

To Configure a Multicast Address 

From the router ( conf ig ) mode, name the group that will use the multicast address, provide the 
address, then tell the router which adapter interface is used: 

Router (conf ig) # ip weep 36 group-address 225 . 1 . 1.1 
Router (conf ig) # interface ethernet 0 
Router (conf ig-if) # end 
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Creating a Redirection Access List and Associating it with a Service Group 

Redirection access lists can contain commands redirecting packets from one network or cache to 
another. The lists also can be used to determine which caches participate in which service groups. 
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The two lists, although similar, have different purposes, and are applied to the router differently. The 
redirection lists are applied with the redirect-list option. The cache bypass lists are applied with the 
group-list argument. Both lists can be identified with either a name or a number. 

Use the following syntax to create a redirection access list. This is partial syntax for this command. 
Access lists are very complicated; refer to the Cisco Web site for complete syntax. 

access-list acl_ID [deny | permit] protocol { [ source_addr source_mask ] 

[ local_addr local_mask ] } 



where: 



acl ID 


Names the access list you are creating. You can use either a name or number. 


deny 


Indicates that you do not want to allow a packet to traverse the Cisco router. By 
default, the router firewall denies all inbound or outbound packets unless you 
specifically permit access. 


permit 


Selects a packet to traverse the PIX firewall. By default, the router firewall denies all 
inbound or outbound packets unless you specifically permit access. 


protocol 


Identifies, by name or number, an IP protocol. This parameter can be one of the 
keywords icmp, ip, tcp, or udp, or an integer in the range 1 to 254 representing an 
IP protocol number. To match any Internet protocol, including ICMP, TCP, and UDP, 
use the keyword ip. 


source addr 


Indicates the address of the network or host from which the packet is being sent. 
Use the keyword any as an abbreviation for an address of 0 . 0 . 0 . 0. 


source mask 


Specifies the netmask bits (mask) to be applied to source addr, if the source 
address is for a network mask. Use the keyword any as an abbreviation for a mask 
of 0 . 0 . 0 . 0. 


local addr 


Indicates the address of the network or host local to the PIX firewall. The 
local addr is the address after NAT has been performed. Use the keyword host, 
followed by addr e s s, as an abbreviation for a mask of 255. 255. 255. 255. 


local mask 


Specifies the netmask bits (mask) to be applied to local addr, if the local address 
is a network mask. Use the keyword host followed by address as an abbreviation 
for a mask of 255.255.255.255. 



To Create a Redirection Access List or a Cache Bypass List 

From the router (conf ig) prompt, name an access list and assign rules to it. 

Router (config) # access-list 100 deny ip any host 126.10.10.10 

Router (conf ig) # access-list 100 permit ip any any 

Router# 

□ The commands above gave the access list a name of 100 . 

□ Denied packets from any protocol to be sent from any host on the 126.10. io. io network. 

□ Permitted packets from any protocol to be sent from any other network. 

To Associate a Redirection Access List with a Specific Service Group 

1 . Create a redirection access list. 
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2. Associate the access list with a specified service group. 

ip weep {web-cache | service -number} [redirect- list access-list ] 

Router (config) # interface ethernet 0/0 

Router (config-if) # ip weep web-cache redirect-list 100 

Router (config-if) # end 
Router# 

To Associate a Cache Bypass Access List with a Specific Service Group 

1. Create a redirection access list, using the syntax discussed above. 

2. Associate the access list with a specified service group. 

ip weep {web-cache | service -number} [group-list access-list ] 

Router (config) # interface ethernet 0 

Router (config-if ) # ip weep web-cache group-list 120 

Router (config-if ) # end 

Router# 

Configuring the Internet-Connected Interface 

WCCP interface settings allow you to configure the Internet-connected adapter interface that will 
redirect Web traffic to the content engine. 

Using the interface commands allows you to: 

□ Enable and prevent packet redirection 

□ Enable reception of multicast packets for service group member routers 

Syntax for configuring an Internet-connected adapter interface (interface settings): 

ip weep [{web-cache | service-number} redirect out | group- listen] | redirect 
exclude in 



where: 



web-cache 


Enables the Web cache service group. 


service -number 


The identification number of the cache service group being controlled by the 
router. Services are identified using a value from 0 to 99. The reverse-proxy 
service is indicated using the value 99. 


redirect out 


Enables packet redirection on an outbound (Internet facing) adapter interface. 


group-listen 


On a router that is a member of a service group, enables the reception of 
pre-defined IP multicast packets. 


redirect 
exclude in 


Prevents packets received on an adapter interface from being checked for 
redirection. If the cache service-group is located on a separate router interface, 
the possibility exists that bypass filters could be enabled on the cache. 



Using Packet Redirection 

WCCP communication among the routers and the ProxySG Appliances can be done by either directly 
addressing protocol packets to each router's and cache's IP address (as illustrated in Figure C-l on 
page 1088) or by sending these packets to a common multicast address as illustrated in Figure C-3, 
below: 



1094 



Appendix C: Using WCCP 




Figure C-3: A Version 2 Configuration Using Multicast Packet Redirection 
You can configure redirection on inbound or outbound interfaces. 

To Configure Redirection on the Outbound Interfaces: 

Use the following syntax to configure redirection on the outbound adapter interface, 
ip weep {web-cache | service -number} redirect out 

From the router (config) prompt, enter the following: 

Router (config) # interface ethernet 0 

Router (config-if) # ip weep web-cache redirect out 

Router (config-if) # end 

To Exclude Packet Redirection on an Inbound Adapter Interface: 

Use the following command to prevent packets received on an adapter interface from being checked 
for redirection. 

ip weep redirect exclude in 

The following example shows how to exclude Blue Coat adapter interface (xx, in this case) and allow 
use of Blue Coat bypass lists: 

From the router (config) prompt, enter the following: 

Router (config) # int xx 

Router (config-if ) # ip weep redirect exclude in 

Router (config-if ) # end 

Enabling Reception of Multicast Packets 

Benefits of using a multicast address include reduced WCCP protocol traffic and the ability to easily 
add and remove caches and routers from a service group without having to reconfigure all service 
group members. You (optionally) set up a multicast group address in "Configuring a Global Multicast 
Group Address". In the following procedure, you enable the reception of the pre-defined IP multicast 
packets to routers that are members of the group. 

Multicast addresses fall within the range 224.0.0.0 to 239.255.255.255. 
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Use the following syntax to configure for multicast discovery of the cache(s). 

ip weep {web-cache | service -number} group-listen 

The following example configures the router to use the WCCP 36 service group to redirect port 80 
destination traffic. WCCP protocol traffic uses multicast address 225.1.1.1. Adapter interface 
"Ethernet 0" is used to receive the multicast WCCP traffic. 

Router (config) # ip weep 36 group-address 225.1.1.1 

Router (config) # interface ethernet 0 

Router (config-if) # ip weep web-cache group-listen 

Router (config-if) # end 

Saving and Viewing Changes 

Once you have made all the changes, you must permanently save them to disk. If not, the changes are 
lost at the next reboot of the router. 

To Save Router Configuration: 

Router# write memory 

To Display all Current WCCP Configuration Settings: 

Use the following syntax to verify the settings in the new router configuration and to ensure that the 
appropriate cache engines are visible to the router. 

show ip weep {web-cache | service-number} [view | detail] 

where 



view 


(Optional) Lists all members of the identified service group and whether they have been 
detected. 


detail 


(Optional) Displays IP and protocol version information about the router. Displays IP, 
protocol version, state, initial and assigned hash, hash allotment, redirected packet, and 
connection time information about the associated cache engine (ProxySG). 



For example: 

Router# show ip weep web-cache view 



Global WCCP Information: 

Service Name: web-cache: 

Number of Cache Engines : 1 

Number of Routers : 1 

Total Packets Redirected: 186 

Redirect Access-list : 120 

Total Packets Denied Redirect: 57 

Total Packets Unassigned : -none- 

Group Access-list : 0 

Total Messaged Denied to Group :0 

Total Authentication Failures :0 
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WCCP Router Informed of : 

86 . 135 . 77. 10 
186 . 135 . 77.20 

WCCP Cache Engines Visible: 

186 . 135 . 77 . 11 

186 . 135 . 77 . 12 

WCCP Cache Engines Not Visible: 
-none- 



Creating a ProxySG WCCP Configuration File 

Once you have the router global and adapter interface settings complete, you must create a WCCP 
configuration file for the ProxySG. These configurations should include the following: 

□ Identify the service group. 

□ Identify the queuing priorities for all defined service groups. 

□ Identify the protocol. 

□ Load balancing caches in a service group. 

□ Identify ports. 

□ Identify the home router as defined in the router configuration. 

□ Identify the packet forwarding method. 

Understanding Packet Forwarding 

By default, Cisco's GRE encapsulation (Generic Routing Encapsulation) is used to forward packets 
from the WCCP router to the caches. If you have a version 2 WCCP router, you can alternatively use 
Layer 2 (L2) rewrites to forward packets, which is faster than GRE and saves network bandwidth. 

Using GRE, redirected packets are encapsulated in a new IP packet with a GRE header. 

Using L2, redirected packets are not encapsulated; the MAC address of the target cache replaces the 
packet's destination MAC address. This different way of directing packets saves you the overhead of 
creating the GRE packet at the router and decoding it at the cache. Also, it saves network bandwidth 
that would otherwise be consumed by the GRE header. 

If you want to continue using GRE, you need not change any settings. To use L2 packet redirection, 
you must add the forwarding option to the ProxySG configuration file. 

If WCCP version 2 is supported, the router sends out a list of forwarding mechanisms supported by 
the router in the first wccp2_i_see_you message. The cache responds with a wccp2_here_i_am 
message. If the router does not send the list, the cache aborts its attempt to join the WCCP service 
group. If the method of forwarding mechanism is not supported by the router, the WCCP2 messages 
from the cache are ignored. 

Caveats for using L2 redirection: 

□ You must use WCCP version 2. 



1097 



Blue Coat Proxy SG Configuration and Management Guide 



□ If a cache is not connected directly to a router, the router does allow the cache to negotiate the 
rewrite method. 

□ The same rewrite method must be used for both packet forwarding and packet return. 

Understanding Cache Load Balancing 

If you use WCCP version 2, you can balance the load on the caches in a service group using one of the 
following methods: 

□ Hash table (default method) 

□ Mask assignment table 

These load-balancing methods are described in the following sections. 

Using A Hash Table for Load Balancing 

When a router receives an IP packet for redirection, it hashes fields within the packet to yield an index 
within the hash table. The packet then is forwarded to the owner ProxySG for servicing. The 
proportion of redirection hash table assigned to each ProxySG can be altered to provide a form of load 
balancing between caches in a service group. 

A hash table is configured by a dynamically elected ProxySG participating in a service group, 
enabling the simultaneous interception of multiple protocols on multiple ports. You can configure up 
to 100 dynamic or standard service groups plus standard service groups. A single service can intercept 
up to eight port numbers. 

Each element in this 256-entry hash table refers to an active ProxySG within the service group. By 
default, each ProxySG is assigned roughly an even percentage of the 256-element redirection hash 
table. Multiple network cards within a ProxySG can participate in the same service group. To the 
routers and other caches, each adapter interface appears as a unique cache. Using this strategy, 
redirected traffic can be better distributed among network interfaces in a cache. 

Using Figure C-4, below, all caches would be assigned 1 /m of the redirection hash table, but since 
Cache 2 and Cache 3 are physically located within the same ProxySG Appliance, that appliance is 
actually assigned 2/m of the redirection hash table. 
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Figure C-4: A Version 2 Configuration Using Multicast Packet Redirection to Multiple Routers, Multiple Caches, 
and a Service Group 

Assigning Percentages 

You can override the default of each ProxySG being assigned roughly an even percentage; the relative 
distribution of the redirection hash table can be specified for each cache. Multiple hash-distributions 
are supported. Also, all, none, or part of a source and/ or destination IP address or port number can be 
used in the hash. Each ProxySG can be assigned a primary -hash-weight value to determine the 
proportion of the 256-element hash table to be assigned. 

If all caches are configured with a 0 primary-hash- weight value (the default) then each ProxySG is 
assigned an equal proportion of the redirection hash table. However, if any ProxySG is configured 
with a non-zero primary-hash-weight, each ProxySG is assigned a relative proportion of the table. 

For instance, consider a configuration with five caches that use a primary-hash- weight defined as {25, 
200, 0, 50, 25}. The total requested weight value is 25+200+0+50+25=300 and, therefore, the proportion 
of the hash table assigned to each ProxySG is 25/300, 200/300, 0/300, 50/300, and 25/300. 

Because one cache did not specify a non-zero primary-hash-weight, that cache is assigned any 
elements within the redirection hash table and, therefore, does not receive any redirected traffic. Also, 
the hash weight can be specified for each caching member within a ProxySG. In Figure C-4, Cache 2 
and Cache 3 can be assigned different weight values. 

Alternate Hash Table 

In some cases, a Web site becomes an Internet hot spot, receiving a disproportional number of client 
traffic relative to other sites. This situation can cause a larger request load on a specific ProxySG 
because the hash element associated with the popular site receives more activity than other hash 
elements. 

To balance the redirection traffic load among the caches, a service group can be configured to use an 
alternate hash function when the number of GRE packets forwarded to the cache exceeds a certain 
number. (If you use L2 forwarding, the ProxySG counts MAC addresses.) Therefore, when a router 
receives an IP packet that hashes to an element flagged as a hot spot, the alternate hash function is 
computed. The ProxySG specified by the new index in the redirection hash table receives the 
redirected packet. 
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Each ProxySG can dynamically determine a hot spot within its assigned portion of the redirection 
hash table. 

Alternate hash tables are only used for dynamic service groups that specify alternate-hash flags 
within their service-flags. The default Web-cache service group cannot use an alternate hash table. 
Instead, a comparable dynamic service group must be created. 

To use hot spot detection, the ProxySG's WCCP configuration file must specify: 
service-flags source-ip-hash 

service -flags de s t inat ion - por t - alternate -hash 

Using Mask Assignment for Load Balancing 

Load balancing using a hash table is a CPU-intensive operation for routers. Even when the service 
group's proxies can handle all of the redirected packets, the router's CPU utilization can sometimes 
reach 100% under heavy load. To continue using the hash method, additional routers would have to 
be deployed to handle the traffic load. 

You can avoid the expense of additional hardware by implementing the mask assignment 
load-balancing method. With the mask assignment method, the router redirects packets using 
hardware acceleration, thus reducing the load on the router CPU. 

The details of mask assignment load balancing are described in the Internet draft Web Cache 
Coordination Protocol V2.0. 

Prerequisites 

The mask assignment method can be used only with the Catalyst 6500 Series switches and Cisco 7600 
series routers. Specifically, the "Supervisor Engine II with Policy Feature Card 2 (PFC2 and newer) and 
MSFC2, 256-MB memory option” is required. 

Implementation 

The ProxySG and router negotiate to determine if mask assignment can be used. Once negotiated, the 
ProxySG includes the mask assignment table in the WCCP2_REDIRECT_ASSIGN message to the 
router. 

The mask assignment table contains a set of mask / value elements. Each mask / value element contains 
a mask and a set of values. The Mask is a 96-bit value (32 + 32 + 16 + 16) that is used to perform a 
bitwise "AND” operation with the TCP/UDP packet's Source IP, Source Port, Destination IP, or 
Destination Port value. The result of the AND computation is then compared to the 96-bit value in the 
value element. If a match is found, the router redirects the TCP/UDP packets to the specified IP 
address (the value element contains the proxy's IP address). If multiple value elements match, the first 
match is used. 

The ProxySG automatically creates a mask assignment table with 64 value elements. By default, the 
table is arranged so that traffic can be evenly distributed to all active Web caches in the Service Group. 
However, you can use the primary-hash-weight command to change how traffic is distributed 
among the Web caches. The effect is similar to using the hash assignment method. 

Default: destination IP 
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Enabling Mask Assignment 

To enable mask assignment load balancing, insert the following command into the WCCP 
configuration file, after the service-group command: 

assignment- type mask 

Command syntax: 

assignment -type hash | mask 

Example: 

; WCCP Settings 
; Version 1.3 
weep enable 
weep version 2 
service -group 9 
forwarding- type L2 
assignment -type mask 
priority 1 
protocol 6 

service-flags ports-def ined 
ports 80 80 80 80 80 80 80 80 
interface 0:0 
home-router 239.192.5.3 

end 

Routers advertise the supported packet return methods for a Service Group using the optional 
Capabilities Info component of the WCCP2_I_SEE_YOU message. If the assignment type mask 
command has been inserted, the ProxySG sends a WCCP2 Here_I_Am message that has the mask 
assignment bit set in the Capability Info component. If the WCCP2 I_See_You message sent by the 
router also has the mask assignment set in the Capability Info component, the ProxySG assumes that 
the negotiation for Mask Assignment is successful. Otherwise, the packet is dropped. 

Modifying the Mask Assignment Table 

You can modify the mask setting to distribute traffic based on Source IP, Source Port, Destination IP, or 
Destination Port. The command syntax is: 

mask-scheme source-ip | source-port | destination-ip | destination-port 

Only one mask-scheme value can be assigned for a service group. 

Example: 

weep enable 
weep version 2 
service -group 9 
forwarding- type L2 
assignment -type mask 
mask-scheme destination-ip 
primary-hash-weight 0 100 
priority 1 
protocol 6 
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service-flags ports-def ined 
ports 80 80 80 80 80 80 80 80 
interface 0 
home-router 10.9.44.1 
end 

Creating a Configuration File 

An example of a file using a dynamic service, as opposed to the default Web-cache service, is shown 
below: 

If using the default Web-cache service, the service group settings priority, protocol, service 
flags, and ports are not used. 

weep enable 
weep version 2 
service -group 9 
forwarding- type L2 
priority 1 
protocol 6 

service -flags destination- ip -hash 
service-flags ports-def ined 
ports 80 21 1755 554 80 80 80 80 
interface 6 

home-router 10.16.18.2 
end 

You can create a configuration file customized for the environment two ways: CLI inline commands or 
through a text file. In either case, the configuration file must include the information required by the 
commands below. 

Syntax to create a customized configuration file: 

service-group {web-cache | service-number} 

[priority priority-number] 

[protocol protocol -number] 

[service- flags hash-bit -identifier] 

[ports portl ... port8] 

home-router [ip-address | domain-name] 

[multicast-ttl [ttl_value] ] 
interface [interface -number] 

[password string] 

[primary-hash-weight interface-number value] 
forwarding- type [GRE | L2] 

Using Optional Negation Syntax, you can create an alternative WCCP configuration file using these 
negative commands; this is especially helpful when testing and debugging. This functionality enables 
you to change some of the configuration settings without altering or reloading the main configuration 
file. 
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[no] service-group {web-cache | service-number} 
[priority priority-number ] 

[protocol protocol - number ] 

[no] service-flags hash-bit- identifier 
[ports portl ...port 8] 

home-router [ip-address \ domain-name ] 

[no] interface [ interface-number ] 

[password string | no password] 
[primary-hash-weight interface-number value] 



where: 



web-cache 


Enables the Web cache service group. If using the Web-cache service 
group for WCCP, the dynamic service group settings (priority, 
protocol, service flags, and ports) are not applicable. 


service -number 


The identification number of the dynamic service group being 
controlled by the router. Services are identified using a value from 0 
to 99. The reverse-proxy service is indicated using the value 99. 


priority-number 


(Applies to a dynamic service group only. A dynamic service group 
is one identified by a service number.) Establishes queuing 
priorities for all defined service groups, based on a priority number 
from 0 through 255, inclusive. 


protocol -number 


(Applies to a dynamic service group only. A dynamic service group 
is one identified by a service number . ) Number of an Internet 
protocol. Protocol -number must be an integer in the range 0 
through 255, inclusive, representing an IP protocol number. 


hash-bit- identifier 


(Applies to a dynamic service group only. A dynamic service group 
is one identified by a service number.) Sets the hash index, for load 
balancing purposes. 

The key associated with the hash-bit-identifier you specify is 
hashed to produce the primary redirection hash table index. For 
instance, if only the destination- ip-hash flag is set, then the 
packet destination IP address is used to determine the index. The 
index is constructed by starting with an initial value of zero and then 
computing an exclusive OR (XOR) of the fields specified in the 
hash-bit identifier. 

If alternative hashing has been enabled, any alternate hash flags are 
processed in the same way and produce a secondary redirection hash 
table index. Alternate hash flags end with the suffix 
"-alternate-hash. " 

For more information using the hashing table, see "Understanding 
Cache Load Balancing" on page 1098. 


source- ip -hash 
(hash -bit- identifier) 


Sets the source IP bit definition within the redirection hash table 
index. 


destination-ip-hash 
(hash-bit- identifier) 


Sets the source IP bit definition within the redirection hash table 
index. 
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source -port -hash 
( hash-bi t- identifier) 


Sets the source port bit definition within the redirection hash table 
index. 


destination-port-hash 
( hash-bi t- identifier) 


Sets the destination port bit definition within the redirection hash 
table index. 


ports-def ined 
( hash-bi t- identifier) 


Sets the port bit definition within the redirection hash table index. 


ports-source 
( hash-bi t- identifier) 


Sets the source port bit definition within the redirection hash table 
index. 


source-ip-alternate- 

hash 

( hash-bi t- identifier) 


Sets the alternate source IP bit definition within the redirection hash 
table index. 


destination- ip - 
alte mate -hash 


Sets the alternate destination IP bit definition within the redirection 
hash table index. 


( hash-bi t- identifier) 




source-port- 
alternate -hash 


The alternate source port bit definition within the redirection hash 
table index. 


( hash-bi t- identifier) 




destination-port- 
alte mate -hash 


Sets the alternate destination port bit definition within the 
redirection hash table index. 


( hash-bi t- identifier) 




multicast-ttl 


Sets the multicast TTL value per WCCP service group. The value 
must be set between 1 and 255. 

If the multicast TTL value is not set, the default value is 1. If the 
home-router address is not multicast, this command is 
non-operational. 


portl...port8 


(Applies to a dynamic service group only. A dynamic service group 
is one identified by a service number.) A zero-terminated list of TCP 
port identifiers. 

Note that this must be a list of exactly eight ports. 

If the service-flags ports-defined flag is set, packets are matched 
against the set of ports supplied. If the service- flags 
port s - source flag is set, the ports are assumed to be source ports. 
Otherwise, the ports are assumed to be destination ports. 
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ip-address 


Indicates the IP address of your network's home router. For version 
2, ip-address can be a multicast address. (Multicast addresses are 
in the range 224 . 0 . 0 . 0 to 239 . 255 . 255 . 255, inclusive.) 

In version 2, multiple IP addresses can be specified for unicast 
addressing. For multicast addresses, only one IP address can be 
specified per service group. 

If you choose to specify the home router IP address, it is important 
that the actual home router IP address and the home router IP 
address specified in this ProxySG configuration file match. If you do 
not already know the IP address of the home router, you can easily 
determine it from the router CLI by using the show ip weep 
command. 


domain-name 


Specifies the domain name of your network's home router. 
Domain-name must be a valid domain name string that will 
successfully resolve on DNS lookup. 


inter face -number 


Specifies the adapter interface number for the service group. You 
cannot use a colon (0 : 0 or 0 : 1 , for example). 


string 


(Applies to a dynamic service group only. A dynamic service group 
is one identified by a service number.) String can be at least one, and 
not more than eight, alphanumeric characters long. 

The password string specified here must match the password string 
declared for the router. 


interface-number 


(When used with the hash identifiers) Specifies the adapter interface 
to which the weight factor is applied to alter the distribution of the 
primary hash table. 


value 


Specifies the weight factor value (0 through 255) that is applied to the 
adapter interface specified to alter the distribution of the primary 
hash table. 


forwarding -type 
[GRE | L2] 


Switches between GRE encapsulation (the default) and L2 MAC 
address rewrite for forwarding packets. If this command is not 
present, GRE encapsulation is used. 



You can create a configuration file customized for the environment through the CLI inline commands 
or through a text file. The CLI inline commands enable WCCP on the ProxySG immediately; the 
drawback is that if any information changes, you must re-create the whole file using the inline 
command. With a text file, if any information changes, you can change the individual line; the 
drawback is that you must download the file again from an HTTP server to the ProxySG. 

To use CLI commands to create a configuration file, continue with the next procedure. To use a text 
editor to create a configuration file, continue with "Creating a Configuration File using a Text File” on 
page 1106. 

Creating a Configuration File using CLI Inline Commands 

For examples of various types of WCCP configurations, see "Examples" on page 1107. 

If you choose to configure through the CLI and the inline command, refer to the example below: 
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SGOS# configure terminal 

SGOS# (config) inline weep eof 

where eof marks the beginning and end of the inline commands. 

For example: 

SGOS# (config) inline weep eof 
weep enable 
weep version 2 
service -group 9 
forwarding- type L2 
priority 1 
protocol 6 

service- flags destination- ip -hash 
service- flags ports-def ined 
ports 80 21 1755 554 80 80 80 80 
interface 6 

home-router 10.16.18.2 

end 

eof 

You created a WCCP configuration file and enabled WCCP on the ProxySG. WCCP setup is complete. 

Creating a Configuration File using a Text File 

If you create a configuration file using a text editor, assign the file the extension . txt. The following ar 
Blue Coat ProxySG configuration file rules: 

□ Only one command (and any associated parameters) is permitted, per line. 

□ Comments must begin with a semicolon ( ; ) or a pound sign (#). 

□ Comments can begin in any column; however, all characters from the beginning of the comment 
to the end of the line are considered part of the comment and, therefore, are ignored. 

For examples of various types of WCCP configurations, see "Examples" on page 1107. 

To Create a Configuration File using a Text Editor and Load the File on a ProxySG 

1. Open a text editor. 

2. Using the commands described in "Syntax to create a customized configuration file:" on 
page 1102, enter the arguments you need. 

3. Copy the configuration file to an FITTP server so that it can be downloaded to the ProxySG. 

4. Enable WCCP and download the WCCP configuration file using the following syntax: 

weep {enable | disable | no} [path config-file-url ] | [version 

vers ion -number] 



where: 



enable 


Enables WCCP on the ProxySG. 


disable 


Disables WCCP on the ProxySG. 


no 


Indicates that you want to clear the current WCCP configuration settings. 
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config-file-url 


Specifies the ProxySG WCCP configuration file or alternate configuration file. 


vers ion- number 


Indicates the version of WCCP that your router is configured to use. If 
version version-number is omitted, it is assumed to be 2. 



For example: 

SGOS# (config) weep enable 

SGOS# (config) weep path http://205.66.255.10/files/wccp.txt 
SGOS# (config) load weep- settings 

Examples 

This section provides detailed examples of both the router and ProxySG configurations for: 

□ Standard HTTP redirection 

□ Standard HTTP redirection and a multicast address 

□ Standard HTTP redirection and a security password 

□ Standard transparent FTP 

□ A service group and alternate hashing 

For information and examples about using WCCP, refer to 

http:/ /www.cisco.com/ univercd/cc/ td/ doc/product/ software/iosl21/121cgcr/ fun_r/frprt3/ frd30 
05.htm. 

Displaying the Router’s Known Caches 

Use the router show command to display information about the ProxySG Appliances that are known 
to the router. 

Router# show ip weep web-caches 

WCCP Web-Cache information: 

IP Address : 192 . 168 . 51 . 102 
Protocol Version: 0.3 
State : Usable 
Initial Hash 

Info : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
Assigned Hash: 

Info : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
Hash Allotment: 256 (100.00%) 

Packets Redirected :0 
Connect Time : 00 : 00 : 31 
Router# exit 

Standard HTTP Redirection 

The web-cache service group enables HTTP traffic redirection on port 80. 
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Router Configuration 

The following example enables standard HTTP traffic redirection on a WCCP version 2-capable Cisco 
router. 

Router (config) # ip weep web-cache 

Router (config) # interface ethernet 0/0 

Router (config-if) # ip weep web-cache redirect out 

Router (config-if) # end 

ProxySG Configuration 

To enable the Web-cache service group within the ProxySG, the following configuration file could be 
loaded. 

# Enable WCCP to allow WCCP protocol communication between 

# the ProxySG Appliance and the home router. 

weep enable 

# By default, the WCCP version 2 protocol is assumed. An 

# explicit "weep version 2" command could be specified here. 

service-group web-cache 

# Specify the address for the router. 

home-router 90.0.0.90 

# Network interface 0 will participate. 

interface 0 

end 

Standard HTTP Redirection and a Multicast Address 

Configuring a multicast address on a WCCP-capable router provides reduced WCCP protocol traffic 
and the ability to easily add and remove caches and routers from a service group without having to 
reconfigure all service group members. 

Router Configuration 

The following example enables the standard HTTP traffic redirection on a WCCP version 2-capable 
Cisco router. In this case, WCCP protocol traffic is directed to the multicast address 226.1.1.1. 

Router (config) # ip weep web-cache group-address 226 . 1 . 1.1 
Router (config) # interface ethernet 0/0 
Router (config-if ) # ip weep web-cache group-listen 
Router (config-if ) # ip weep web-cache redirect out 

Router (config-if ) # end 

ProxySG Configuration 

To enable the standard Web-cache service group within the ProxySG, the following configuration file 
should be loaded. In this example, both network interfaces 0 and 1 participate within the service 
group. Both interfaces send and receive WCCP protocol packets by way of the multicast address. 

# Enable WCCP to allow WCCP protocol communication between 

# the ProxySG Appliance and the home router. 

weep enable 

# By default, the WCCP version 2 protocol is assumed. An 

# explicit "weep version 2 " command could be specified here. 

service-group web-cache 
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# Specify the multicast address. 

home -router 239.192.5.3 

# Network interface 0 will participate. 

interface 0 

# Network interface 1 will also participate. 

interface 1 
end 

Standard HTTP Redirection Using a Security Password 

A simple eight-character password is configured within the router. This password must match the 
password configured within the ProxySG. 

Router Configuration 

The following example enables standard HTTP traffic redirection on a WCCP version 2-capable Cisco 
router. 

Router (config) # ip weep web-cache password 29gy8c2 

Router (config) # interface ethernet 0 

Router (config-if) # ip weep web-cache redirect out 

Router (config-if) # end 

ProxySG Configuration 

To enable the standard WCCP version 2 service group within the ProxySG, the following 
configuration file could be loaded. 

# Enable WCCP to allow WCCP protocol communication between 

# the ProxySG Appliance and the home router. 

weep enable 

# By default, the WCCP version 2 protocol is assumed. An 

# explicit "weep version 2" command could be specified 

# here . 

service-group web-cache 

# Specify the address for the router. 

home-router 90.0.0.90 

# Network interface 0 will participate. 

interface 0 
password 29gy8c2 
end 

Standard Transparent FTP 

In WCCP version 1, only HTTP traffic on port 80 could be redirected. In WCCP version 2, you can 
create a numbered service group that redirects other protocols on other ports. 

You set the service group on the router, and tell the ProxySG which ports should be redirected. 

Router Configuration 

In this configuration, you create a new service group that you are dedicating to FTP redirects. 
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# Enables the service group that redirects ports besides 80. 

Router (config) # ip weep 10 

# Enables a service group that allows user-defined 

# ports to be redirected. 

Router (config) # int eO 

Router (config-if) # ip weep 10 redirect out 

ProxySG Configuration 

In this configuration, you take the service group created by the router and assign the characteristics to 
the group. 

SGOS# (config) inline weep eof 

weep enable 

service-group 10 

interface 0 

home-router 10 . 1 . 1.1 

protocol 6 

priority 1 

service- flags ports-defined 
service- flags destination -port -hash 
ports 20 21 80 80 80 80 80 80 
eof 

Reverse Proxy Service Group 

This service group redirects IP packets for TCP destination port 80 traffic by hashing the source IP 
address. 

Router Configuration 

The following example enables the special ProxySG service group on a WCCP-capable router. 

Router (config) # ip weep 99 
Router (config) # interface ethernet 0/0 
Router (config- if ) # ip weep 99 redirect out 
Router (config-if ) # end 

ProxySG Configuration 

To configure the special ProxySG service group on the appliance, a dynamic service group must be 
created as illustrated by the following example. 

# Enable WCCP to allow WCCP protocol communication between 

# the ProxySG Appliance and the home router. 

weep enable 

# By default, the WCCP version 2 protocol is assumed. An 

# explicit "weep version 2 " command could be specified here. 

# Service Group 99 is specially identified within the router 

# as representing the ProxySG Appliance service. 

service-group 99 

# Specify the address for the router. 

home -router 90.0.0.90 

# Network interface 0 will participate. 

interface 0 
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# Specify the TCP protocol. 

protocol 6 

# The hash should be based on the source IP address. 

service- flags source- ip-hash 
end 

Service Group with Alternate Hashing 

You can create a special service group on a WCCP-capable router that uses alternate hashing when hot 
spots are detected. This service group redirects IP packets by hashing the source IP address. 

Router Configuration 

In this configuration, you create a new service group that you are dedicating to Website hot spots. 
Router (config) # ip weep 5 
Router (config) # interface ethernet 0/0 
Router (config-if) # ip weep 5 redirect out 
Router (config-if) # end 

ProxySG Configuration 

To configure this special service group on the ProxySG, a dynamic service group must be created. 

# Enable WCCP to allow WCCP protocol communication between 

# the ProxySG Appliance and the home router. 

weep enable 

# By default, the WCCP version 2 protocol is assumed. An 

# explicit "weep version 2" command could be specified here. 

# Service Group 5 is created to redirect standard HTTP 

# traffic and use an alternate hash function based on the 

# source IP address, if necessary, 
service-group 5 

# Specify the address for router 1 . 

home-router 90.0.0.90 

# Specify the address for router 2 . 

home -router 90.0.1.5 

# Network interface 0 will participate. 

interface 0 

# Specify the TCP protocol. 

protocol 6 

# The following two flags specify that a hash function based 

# on the destination IP address should be applied first. If 

# a hot-spot is detected, then an alternate hash 

# function using the source IP address should be used, 
service -flags destination- ip -hash 

service -flags source -ip -alternate -hash 
end 
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Troubleshooting: Home Router 

If you install WCCP settings and then later upgrade the Cisco IOS software or change network 
configuration by adding a device with a higher IP address, the change might result in a different home 
router IP assignment. WCCP might or might not work under these conditions, and performance 
might decrease. If you upgrade the router software or change the network configuration, verify that 
the actual home router IP address and home router IP address in the WCCP configuration match. 

To Verify the Home Router IP Address Matches the Home Router IP Address Listed in the WCCP 
Configuration 

1. From the router CLI, view the WCCP configuration: 

Router# (config) show ip weep 

The home router information appears, similar to the example below: 

Global WCCP information: 

Router information: 

Home router Identifier : 195 . 200 . 10 . 230 
Protocol Version: 2.0 

2. From the Blue Coat ProxySG, verify that the home router IP address specified in the ProxySG 
WCCP configuration file is the same as the actual home router IP address discovered through the 
router CLI command. The following is a ProxySG WCCP configuration file showing the same 
home router IP as in the example above: 

SGOS# show weep config 

; WCCP Settings 
/Version 1.3 
weep enable 
weep version 2 
service-group web-cache 
interface 1 

home-router 195.200.10.230 
end 

In this case, the two home router identifiers match. 

Identifying a Home Router/Router ID Mismatch 

The following is some helpful information for resolving a home-router /Router ID mis-match that 
results in the router crashing the ProxySG. This situation can occur when the router interface is set to a 
higher IP address than the home-router and WCCP messages show w/bad rcv_id. 

WCCP version 1 does not care what home router the cache had configured. So if you upgrade from 
WCCP version 1 to WCCP version 2, the router might pick a different IP address than was configured 
as a home router in the cache. 

This means that a mismatch can occur after an upgrade. 

ProxySG Configuration 

Use the show weep statistics command to identify the configured home router and the highest 
router IP. 
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SGOS# (config) show weep statistics 



Service Group ident . 
Home Routers : 

Hotspots announced 
Assignment state 
Designated Cache : 

Announcement key # 
Cache view change # 
Router View Changed 
Recent hit count 
Primary hit count 
Alternate hit count 
Instance IP address : 
Sequence info 
Query response info: 
Active 

Primary hash weight 
Hotspot information 
Total assign weight 
Router IP address 
Receive # 

Change # 

Activation time 
Last I-See-You time 
Active caches 
Assignment key 
Router state 
Cache 
Active 



10 . 



10 . 



2.3. 

: 0 



: 512 , 1 , 9 , 1,6,18, 1755,554,20,21,80,80,80,80 

.224 <<========Conf igured Home Router IP 

: idle 

.228 <<=======Blue Coat IP 



10.2.3 



: 13 <<==== # times cache view changed 

0 
0 
0 
0 

,228 



<<=======Blue Coat IP 



: 10 .2.3. 231 , 636 



0 , 0,0 



00 : 
01 : 



17:58 UTC 
08:58 UTC 



: 10. 2. 3. 231 «=======Router ID/Highest IP on Router 

636 
4 

Wed, Jan 30 2002 
Wed, Jan 30 2002 
10.2.3 .228 
10.2.3 .228,2 
active 

10.2.3 . 22 8 , L , D 
: 1 



Notice that .231 is highest IP on router and is automatically selected as the home router, even 
though .224 is the configured home router IP. 

You can also use the show weep configuration command if you already know the highest IP and 
just want to know what the ProxySG identifies as the home-router. 

SGOS# (config) show weep configuration 

; WCCP Settings 
/Version 1.3 
weep enable 
weep version 2 
service -group 9 
interface 0 

home-router 10.2.3.224 

protocol 6 
priority 1 

service-flags ports-def ined 
service -flags destination -ip -hash 
ports 1755 554 20 21 80 80 80 80 
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Router Configuration 

The configuration below reveals that two interfaces are active on the router, and that one of the IP 
addresses is higher than the home router configured in the ProxySG configuration file. The higher IP 
address takes over duties as the home router, causing a mismatch between the router and the 
ProxySG. 

Router# show conf 

Using 689 out of 129016 bytes 

version 12 . 1 

service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 
hostname NachoL3 

enable secret 5 $l$r6nJ$dr58AZ . ZDg6RKA6MYeGRb . 
enable password nacho 
ip subnet -zero 
no ip routing 
ip weep 9 

interface FastEthernetO/O 
ip address 10.2.3.224 255.255.255.0 

ip weep 9 redirect out 
no ip route -cache 
no ip mroute- cache 
speed 100 
half -duplex 

; 

interface FastEthernetO/1 

ip address 10.2.3.231 255.255.255.0 

no ip route-cache 
no ip mroute -cache 
speed 100 
half -duplex 

Correcting a Home Router Mismatch 

The home router must have the same IP address on both the router and the ProxySG. Every time a 
higher IP address is introduced to the router, the higher address becomes the home router. 

On a WCCP router, the Router Identifier parameter is dynamically assigned. It cannot be 
manually configured. 

To Set the Correct Home Router IP Address on the ProxySG: 

You cannot edit a WCCP configuration file created by the SGOS inline commands. You must recreate 
the configuration file. For more information on creating a WCCP configuration file using CLI 
commands on a ProxySG, see "Creating a Configuration File using CLI Inline Commands" on 
page 1105. 

If you created a text file and downloaded it, you can edit the file and then download it again to the 
ProxySG. For more information for editing the WCCP text file and downloading it, see "Creating a 
Configuration File using a Text File" on page 1106. 
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Tips 

□ If you use IP spoofing with WCCP, do the following for best results: 

The ip weep redirect exclude in command should be applied to the adapter to which the 
ProxySG is attached. 

□ For L2 forwarding, the ProxySG should be directly connected to the router interface. 



1115 



Blue Coat Proxy SG Configuration and Management Guide 



1116 



Appendix D:RIP Commands 



You can place any of the commands below into a Routing Information 
text file. You cannot edit a RIP file through the command line, but you 
the inline rip- settings command. 

Once the file is complete, place it on an HTTP or FTP server accessible 
following commands to install the file on the ProxySG: 

At the (config) command prompt: 

SGOS# (conf ig) rip path url 
SGOS# (config) load rip-settings 

For more information on installing the RIP configuration file, see "Section F: Using RIP" on page 105. 



Protocol (RIP) configuration 
can overwrite a RIP file using 

to the ProxySG and use the 



net 

net Nname [/mask ] gateway Gname metric Value {passive | active | external} 
Syntax 



Parameters 


Description 


Nname 


Name of the destination network. It can be a symbolic network 
name, or an Internet address specified in dot notation. 


/ mask 


Optional number between 1 and 32 indicating the netmask 
associated with Nname. 


Gname 


Name or address of the gateway to which RIP responses should be 
forwarded. 


Value 


The hop count to the destination host or network. A net Nname/ 32 
specification is equivalent to the host Hname command. 


passive | active | 
external 


Specifies whether the gateway is treated as passive or active, or 
whether the gateway is external to the scope of the RIP protocol. 



host 



host Hname gateway Gname metric Value {passive | active | external} 
Syntax 



Parameters 


Description 


Hname 


Name of the destination network. It can be a symbolic network 
name, or an Internet address specified in dot notation. 
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Parameters 


Description 


Gname 


Name or address of the gateway to which RIP responses should be 
forwarded. It can be a symbolic network name, or an Internet 
address specified in dot notation. 


Value 


The hop count to the destination host or network. A net Nname/ 32 
specification is equivalent to the host Hname command. 


passive | active | 
external 


Specifies whether the gateway is treated as passive or active, or 
whether the gateway is external to the scope of the RIP protocol. 



RIP Parameters 

Lines that do not start with net or host commands must consist of one or more of the following 
parameter settings, separated by commas or blank spaces: 



Parameters 


Description 


if = [0 | 1 | 2 | 3] 


Specifies that the other parameters on the line apply to the interface 
numbered 0,1,2, or 3 in SGOS terms. 


passwd=XXX 


Specifies an RIPv2 password included on all RIPv2 responses sent 
and checked on all RIPv2 responses received. The password must 
not contain any blanks, tab characters, commas or '#' characters. 


no ag 


Turns off aggregation of subnets in RIPvl and RIPv2 responses. 


no_super_ag 


Turns off aggregation of networks into supernets in RIPv2 
responses. 


passive 


Marks the interface to not be advertised in updates sent through 
other interfaces, and turns off all RIP and router discovery through 
the interface. 


no rip 


Disables all RIP processing on the specified interface. 


no ripvl in 


Causes RIPvl received responses to be ignored. 


no ripv2 in 


Causes RIPv2 received responses to be ignored. 


ripv2 out 


Turns off RIPvl output and causes RIPv2 advertisements to be 
multicast when possible. 


ripv2 


Is equivalent to no ripvl in and no ripvl out. This 
parameter is set by default. 


no_rdisc 


Disables the Internet Router Discovery Protocol. This parameter is 
set by default. 


no_solicit 


Disables the transmission of Router Discovery Solicitations. 


send_solicit 


Specifies that Router Discovery solicitations should be sent, even on 
point-to-point links, which by default only listen to Router 
Discovery messages. 


no rdisc adv 


Disables the transmission of Router Discovery Advertisements. 



1118 



Appendix D: RIP Commands 



Parameters 


Description 


rdisc adv 


Specifies that Router Discovery Advertisements should be sent, 
even on point-to-point links, which by default only listen to Router 
Discovery messages. 


bcast_rdisc 


Specifies that Router Discovery packets should be broadcast instead 
of multicast. 


rdisc_pref =N 


Sets the preference in Router Discovery Advertisements to the 
integer N. 


rdisc interval=N 


Sets the nominal interval with which Router Discovery 
Advertisements are transmitted to N seconds and their lifetime to 
3*N. 


trust gateways rname 


Causes RIP packets from that router and other routers named in 
other trust_gateway keywords to be accept, and packets from other 
routers to be ignored. 


redirect ok 


Causes RIP to allow ICMP Redirect messages when the system is 
acting as a router and forwarding packets. Otherwise, ICMP 
Redirect messages are overridden. 



Proxy SG-Specific RIP Parameters 



The following RIP parameters are unique to ProxySG configuration: 



Parameters 


Description 


supply routing info 
-or- 

advertise routes 


- s option: 

Supplying this option forces routers to supply routing information 
whether it is acting as an Internetwork router or not. This is the 
default if multiple network interfaces are present or if a 
point-to-point link is in use. 

-g option: 

This flag is used on Internetwork routers to offer a route to the 
'default' destination. This is typically used on a gateway to the 
Internet, or on a gateway that uses another routing protocol whose 
routes are not reported to other local routers. 




-h option: 

Suppress extra host routes advertise host route 
-m option: 

Advertise host route on multi-homed hosts 
-A option: 

Ignore_authentication / / 


no_supply_ 
routing info 


- q option: 
opposite of -s. 


no rip out 


Disables the transmission of all RIP packets. This setting is the 
default. 
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Parameters 


Description 


no ripvl out 


Disables the transmission of RIPvl packets. 


no ripv2 out 


Disables the transmission of RIPv2 packets. 


rip out 


Enables the transmission of RIPvl packets. 


ripvl out 


Enables the transmission of RIPvl packets. 


rdisc 


Enables the transmission of Router Discovery Advertisements. 


ripvl 


Causes RlPvl packets to be sent. 


ripvl in 


Causes RlPvl received responses to be handled. 



Using Passwords with RIP 

The first password specified for an interface is used for output. All passwords pertaining to an 
interface are accepted on input. For example, with the following settings: 

if=0 passwd=aaa 
if=l passwd=bbb 
passwd=ccc 

Interface 0 accepts passwords aaa and ccc, and transmits using password aaa. Interface 1 accepts 
passwords bbb and ccc, and transmits using password bbb. The other interfaces accept and transmit 
the password ccc . 
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Blue Coat Systems has a number of resources to provide diagnostic information: 

□ Heartbeats: Enabled by default. Heartbeats (statistics) are a primary diagnostic tool used by Blue 
Coat, allowing them to proactively monitor the health of ProxySG appliances. 

□ Core images: Created when there is an unexpected system restarted. This stores the system state at 
the time of the restart, enhancing the ability for Blue Coat to determine the root cause of the 
restart. 

□ Syslnfo (System Information): Syslnfo provides a snapshot of statistics and events on the ProxySG. 

□ PCAP: An onboard packet capture utility that captures packets of Ethernet frames going in or out 
of a ProxySG. 

□ Policy trace: A policy trace can provide debugging information on policy transactions. This is 
helpful, even when policy is not the issue. For information on using policy tracing, refer to 
Appendix B: "Troubleshooting" in the Blue Coat ProxySG Content Policy Language Guide. 

□ Event Logging: The event log files contain messages generated by software or hardware events 
encountered by the ProxySG. For information on configuring event logging, see "Event Logging 
and Notification” on page 951. 

O Access Logging: Access logs allow for analysis of Quality of Service, content retrieved, and other 
troubleshooting. For information on Access Logging, see Chapter 20: "Access Logging" on page 
887. 

□ CPU Monitoring: With CPU monitoring enabled, you can determine what types of functions are 
taking up the majority of the CPU. 

To test connectivity, use the following commands from the enable prompt: 

□ ping: Verifies that a particular IP address exists and is responding to requests. 

□ traceroute: Traces the route from the current host to the specified destination host. 

D test http get path_to_URL: Makes a request through the same code paths as a proxied client. 

□ display path_to_URL : Makes a direct request (bypassing the cache device). 

□ show services: Verifies the port of the Management Console configuration. 

D show policy: Verifies if policy is controlling the Management Console. 

For information on using these commands, refer to Chapter 2: "Standard and Privileged Mode 

Commands" in the Blue Coat ProxySG Command Line Reference. 



Note: If you cannot access the Management Console at all, be sure that you are using HTTPS 

(https : / /ProxySG_iP_address: 8 0 82 ) . This more secure option was added in SGOS4.X. 
If you want to use HTTP, you must explicitly enable it before you can access the 
Management Console. 
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This appendix discusses the following topics: 

□ "Diagnostic Reporting (Service Information)" on page 1122. This includes taking snapshots of the 
system. 

□ "Packet Capturing (the PCAP Utility)" on page 1130. 

□ "Core Image Restart Options" on page 1136. 

□ "Diagnostic Reporting (Heartbeats)" on page 1137. 

□ "Diagnostic Reporting (CPU Monitoring)" on page 1139 

If the ProxySG does not appear to work correctly and you are unable to diagnose the problem, contact 
Blue Coat Technical Support. 

Diagnostic Reporting (Service Information) 

The service information options allow you to send service information to Blue Coat using either the 
Management Console or the CLI. You can select the information to send, send the information, view 
the status of current transactions, and cancel current transactions. You can also send service 
information automatically in case of a crash. 

Sending Service Information Automatically 

Enabling automatic service information allows you to enable the transfer of relevant service 
information automatically whenever a crash occurs. This saves you from initiating the transfer, and 
increases the amount of service information that Blue Coat can use to solve the problem. The core 
image, system configuration, and event log are system-use statistics that are sent for analysis. If a 
packet capture exists, it is also sent. 



Important: A core image and packet capture can contain sensitive information — for example, 

parts of an HTTP request or response. The transfer to Blue Coat is encrypted, and 
therefore secure; however, if you do not want potentially sensitive information to be 
sent to Blue Coat automatically, do not enable the automatic service information 
feature. 



To Send Service Information Automatically through the Management Console 
1. Select Maintenance>Service lnformation>Send lnformation>General. 
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General Send Service Information 

Aulo Send Settings 

□ Enable auto-send (Will also enable core image generation) 
Auto Send Service Request Number:| 



Bandwidth Class Settings 

Service Information Bandwidth Class 



| Apply || Cancel || Help 

Figure E-5: Service Information General Tab 

2. To send core image service information to Blue Coat automatically, select Enable auto-send. 

3. Enter the service-request number that you received from a Technical Support representative into 
the Auto Send Service Request Number field (the service-request number is in the form xx-xxxxxxx or 
x-xxxxxxx). 

4. Click Apply. 

5. (Optional) To clear the service-request number, clear the Auto Send Service Request Number field 
and click Apply. 

To Send Service Information Automatically through the CLI 

1 . To enable (or disable) the automatic service information feature, enter the following commands at 
the (config) command prompt: 

SGOS# (config) diagnostics 

SGOS# (config diagnostics) service-info 

SGOS# (diagnostics service- inf o) auto {enable | disable} 

SGOS# (diagnostics service- inf o) auto sr-number sr_number 



where: 



enable 




Enables the automatic service information feature. 


disable 




Disables the automatic service information 
feature. 


sr-number 


sr number 


Sets the service-request number for the automatic 
service information feature. 



2. (Optional) To clear the service-request number, enter the following command: 
SGOS# (diagnostics service-info) auto no sr-number 
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Managing the Bandwidth for Service Information 

You can control the allocation of available bandwidth for sending service information. Some service 
information items are large, and you might want to limit the bandwidth used by the transfer. 
Changing to a new bandwidth management class does not affect service information transfers already 
in progress. However, changing the details of the bandwidth management class used for service 
information, such as changing the minimum or maximum bandwidth settings, affects transfers 
already in progress if that class was selected prior to initiating the transfer. 



Note: Before you can manage the bandwidth for the automatic service information feature, you 

must first create an appropriate bandwidth-management class. See Chapter 10: 
"Bandwidth Management" on page 489 for information about creating and configuring 
bandwidth classes. 



To Manage Bandwidth for Service Information through the Management Console 

1. Select Maintenance>Service lnformation>Send lnformation>General. 

2. To manage the bandwidth of automatic service information, select a bandwidth class from the 
Service Information Bandwidth Class drop-down menu. 

3. Click Apply. 

4. (Optional) To disable the bandwidth-management of service information, select none from the 
Service Information Bandwidth Class drop-down menu; click Apply. 

To Manage Bandwidth for Service Information through the CLI 

1. To manage the bandwidth of automatic-service information, enter the following command: 

SGOS# (diagnostics service- inf o) bandwidth-class bandwidth_class_name 

where bandwidth_class_name is the name of the bandwidth class that you have created and 
configured to manage the bandwidth of service information. 

2. (Optional) To disable the bandwidth-management of service information, enter the following 
command: 

SGOS# (diagnostics service-info) no bandwidth-class 

Configure Service Information Settings 

The service information options allow you to send service information to Blue Coat using either the 
Management Console or the CLI. You can select the information to send, send the information, view 
the status of current transactions, and cancel current transactions using either the Management 
Console or the CLI. For information about sending service information automatically, see "Sending 
Service Information Automatically" on page 1122. 



Important: You must specify a service-request number before you can send service information. 

See Blue Coat Technical Support at: 

http://www.bluecoat.com/ support /index.html for details on opening a service 
request ticket. 
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The following list details information that you can send: 

□ Packet Capture 

□ Event Log 

□ Memory Core 

□ SYSInfo 

□ Access Logs (can specify multiple) 

□ Snapshots (can specify multiple) 

□ Contexts (can specify multiple) 

To Send Information through the Management Console 

1. Select Maintenance>Service lnformation>Send lnformation>Send Service Information. 

General Send Service Information 

- Send Service Information 

Service Request Number: 

Information to send: 

Packet Capture (Unknown) Q Event Log (221 .1 84) 

M emory Core (U nknown) □ SYS I nfo (U nknown) 

O Access Logs | Select access logs to send 

|—| Snapshots 

d Contexts I Select contexts to send 

Select Newest 

[ Send | | View Progress ] 



Help 

Figure E-6: Send Service Information Tab 

2. Enter the service-request number that you received from a Technical Support representative (the 
service-request number is in the form xx-xxxxxxx or x-xxxxxxx). 

3. Select the appropriate checkboxes (as indicated by a Technical Support representative) in the 
Information to send field. 



Note: Options for items that you do not have on your system are grayed out and you cannot 

select that checkbox. 



4. (Optional) If you select Access Logs, Snapshots, or Contexts, you must also click Select access logs to 
send. Select snapshots to send, or Select contexts to send and complete the following steps in the 
corresponding dialog that appears: 
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• Select Snapshots To Send 



^jnjxj 



Snapshots Selected 



Size Newest 



Remove From Selected 



Snapshots Not Selected 



Size Newest 



Snapshot sysinfo 


Unknown 


yes 


S napshot_sysinf o_stats 


Unknown 


yes 



Add To Selected 



OK | Cancel | 

Figure E-7: Select Snapshots to Send Dialog 

• To select information to send, highlight the appropriate selection in the Access 
Logs/Snapshots/Contexts Not Selected field and click Add to Selected. 

• To remove information from the Access Logs/Snapshots/Contexts Selected field, highlight the 
appropriate selection and click Remove from Selected. 

• Click Ok. 

5. Click Send. 

6. Click Ok in the Information upload started dialog that appears. 




Figure E-8: Information Upload Started Dialog 

7. (Optional) Click View Progress to open a window displaying the current transactions in progress; 
click Ok to close the window. 



1126 



Appendix E: Diagnostics 



To Send Information through the CLI 

At the (config) command prompt, enter the following commands: 

SGOS# (config) diagnostics 
SGOS# (config diagnostics) service-info 
SGOS# (config service-info) view available 
SGOS# (config service-info) send sr_number 
one_or_more_commands_from_view_available 
SGOS# (config service-info) view status 

SGOS# (config service-info) cancel {all | one_or_more_from_view_status} 
SGOS# (config service-info) exit 



where: 



cancel 


all 


Cancels all service information being sent to Blue 
Coat. 


one or more from view 
status 


Cancels certain service information items being 
sent to Blue Coat. These items can be chosen from 
the list provided by the view status command. 


send 


sr number 


Specifies the service-request number to send to 
Blue Coat (you must also select one or more of the 
view available commands). 


one or more commands 
from view available 


Specifies the command or commands to send to 
Blue Coat (you must also specify a service-request 
number). Choose commands from those listed 
under the view available command . 


view 


available 


Shows the list of service information than can be 
sent to Blue Coat. 


status 


Shows the transfer status of service information to 
Blue Coat. 


exit 




Exits configure diagnostics service-info mode and 
returns to configure diagnostics mode. 



Example: 

SGOS# (config) diagnostics 

SGOS# (config diagnostics) service-info 

SGOS# (diagnostics service-info) view available 

Service information that can be sent to Blue Coat 



Name 

Event_log 

System_inf ormation 

Snapshot_sysinfo 

Snapshot_sysinfo_stats 



Approx Size (bytes) 

188,416 

Unknown 

Unknown 

Unknown 



SGOS# (diagnostics service- inf o) send 1-4974446 event_log system_inf ormation 
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snapshot_sysinfo 

Sending the following reports 

Event_log 

System_inf ormation 
Snapshot_sysinfo 

SGOS# (diagnostics service-info) view 
Name 

Event_log 
Snapshot_sysinf o 
Event_log 

System_inf ormation 

SGOS# (diagnostics service- inf o) exit 
SGOS# (config diagnostics) exit 
SGOS# (config) 



status 

Transferred Total Size % Done 

Transferred successfully 
Transferred successfully 
Transferred successfully 
Transferred successfully 



Creating and Editing Snapshot Jobs 



To Create a New Snapshot Job through the Management Console 

1. Select Maintenance>Service lnformation>Snapshots. 

Snapshots 

- Snapshots 

Snapshot Jobs 




| New ~| | Edit ] | Delete | 

| View All Snapshots | 

Apply |( Cancel |[ Help 

Figure E-9: Snapshots Tab 

2. Click New. 

3. Enter a snapshot job into the Add list item dialog that displays; click Ok. 

4. Click Apply. 

5. (Optional) To view snapshot job information, click View All Snapshots. Close the window that 
opens when you are finished viewing. 

To Create a New Snapshot Job through the CLI 

At the (config) command prompt, enter the following commands: 
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SGOS# (config) diagnostics 

SGOS# (config diagnostics) snapshot create snapshot_name 



To Edit an Existing Snapshot Job through the Management Console 

1. Select Maintenance>Service lnformation>Snapshots. 

2. Select the snapshot job you want to edit (highlight it). 

3. Click Edit. 

The Edit Snapshot dialog displays. 



Edit Snapshot 



E dit S napshol J ob sysinf o - 

T argel: 

Interval (minutes): 1440 



Q| 



View URL List 



Total Number To Take: 



0 infinite 



Maximum Number To Store: j 30 
0 Enabled 



Status: 



Enabled Next snapshot: 2005-1 2-01 00:00:00 UTC 



View Snapshots 



Clear Snapshots 



[ OK ] [ Cancel ] 

Figure E-10: Edit Snapshot Dialog 

4. Enter the following information into the Edit Snapshot fields: 

• Target: Enter the object to snapshot. 

• Interval (minutes): Enter the interval between snapshot reports. 

• Total Number To Take: Enter the total number of snapshots to take or select Infinite to take an 
infinite number of snapshots. 

• Maximum Number To Store: Enter the maximum number of snapshots to store. 

• Enabled: Select this to enable this snapshot job or deselect it to disable this snapshot job. 

5. (Optional) Click View URL List to open a window displaying a list of URLs; close the window when 
you are finished viewing. 

6. (Optional) Click View Snapshots to open a window displaying snapshot information; close the 
window when you are finished viewing. 

7. (Optional) Click Clear Snapshots to clear all stored snapshot reports. 
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To Edit an Existing Snapshot Job through the CLI 



At the (config) 

SGOS# (conf 
SGOS# (conf 
SGOS# (conf 
SGOS# (conf 
SGOS# (conf 
SGOS# (conf 
SGOS# (conf 
SGOS# (conf 
SGOS# (conf 
SGOS# (conf 
SGOS# (conf 



command prompt, enter the following commands: 
ig) diagnostics 

ig diagnostics) snapshot edit snapshot_name 
ig snapshot snapshot_name ) clear-reports 
ig snapshot snapshot_name ) 
ig snapshot snapshot_name ) 
ig snapshot snapshot_name) 
ig snapshot snapshot_name ) 
ig snapshot snapshot_name) 
ig snapshot snapshot_name) 
ig snapshot snapshot_name) 
ig snapshot snapshot_name) 



disable 

enable 

exit 

interval minutes 

keep number_to_keep (from 1 - 100) 
take infinite | number_to_take 
target obj ect_to_fetch 

view 



where: 



clear-reports 




Clears all stored snapshots reports. 


disable 




Disables this snapshot job. 


enable 




Enables this snapshot job. 


exit 




Exits configure diagnostics snapshot 
name mode and returns to configure 
diagnostics service-info mode. 


interval 


minutes 


Specifies the interval between 
snapshots reports in minutes. 


keep 


number to keep (from 1 - 
100) 


Specifies the number of snapshot 
reports to keep. 


take 


infinite | number to take 


Specifies the number of snapshot 
reports to take. 


target 


object to fetch 


Specifies the object to snapshot. 


view 




Displays snapshot status and 
configuration. 



Packet Capturing (the PCAP Utility) 

You can capture packets of Ethernet frames going into or leaving a ProxySG. Packet capturing allows 
filtering on various attributes of the frame to limit the amount of data collected. The maximum PCAP 
size allowed is 100MB. Any packet filters must be defined before a capture is initiated, and the current 
packet filter can only be modified if no capture is in progress. 

The pcap utility captures all received packets that are either directly addressed to the ProxySG 
through an interface's MAC address or through an interface's broadcast address. The utility also 
captures transmitted packets that are sent from the ProxySG. The collected data can then be 
transferred to the desktop or to Blue Coat for analysis. 
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Note: Packet capturing increases the amount of processor usage performed in TCP/IP. 

To analyze captured packet data, you must have a tool that reads Packet Sniffer Pro 1.1 
files (for example. Ethereal or Packet Sniffer Pro 3.0). 



PCAP File Name Format 

The name of a downloaded packet capture file has the format: 

bluecoa.t_date_filter-expression.cap, revealing the date and time (UTC) of the packet capture 
and any filter expressions used. Because the filter expression can contain characters that are not 
supported by a file system, a translation can occur. The following characters are not translated: 

□ Alphanumeric characters (a-z, A-Z, 0-9) 

□ Periods (.) 

Characters that are translated are: 

□ Space (replaced by an underscore) 

□ All other characters (including the underscore and dash) are replaced by a dash followed by the 
ASCII equivalent; for example, a dash is translated to -2D and an ampersand (&) to -26 . 

Common PCAP Filter Expressions 

Packet capturing allows filtering on various attributes of the frame to limit the amount of data 
collected. PCAP filter expressions can be defined in the Management Console or the CLI. Below are 
examples of filter expressions; for PCAP configuration instructions, see "Configuring Packet 
Capturing" on page 1132. 

Some common filter expressions for the Management Console and CLI are listed below. The filter uses 
the Berkeley Packet Filter format (BPF), which is also used by the tcpdump program. A few simple 
examples are provided below. If filters with greater complexity are required, you can find many 
resources on the Internet and in books that describe the BPF filter syntax. 



Note: Some qualifiers must be escaped with a backslash because their identifiers are also 

keywords within the filter expression parser. 



ip proto protocol 


where protocol is a number or name (icmp, udp, top). 


ether proto protocol 


where protocol can be a number or name (ip, arp, rarp). 



Table E.1: Common Filter Expressions 



Filter Expression 


Packets Captured 


ip host 10.25.36.47 


Captures packets from a specific host with IP address 10.25.36.47. 
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Table E.1: Common Filter Expressions 



Filter Expression 


Packets Captured 


not ip host 10.25.36.47 


Captures packets from all IP addresses except 10.25.36.47. 


ip host 10.25.36.47 and ip 
host 10.25.36.48 


Captures packets from two IP addresses: 10.25.36.47 and 
10.25.36.48. 


ether host 00 : eO : 81 : 01 : f 8 : f c 


Captures packets from MAC address 00:e0:81:01:f8:fc:. 


port 80 


Captures packets to port 80. 


Ip src bluecoat.com 


Captures all packets that came from the host bluecoat . com to the 
ProxySG. 


Host example.com and tcp 


Captures all TCP packets sent between the host example . com and 
the ProxySG. 



Using Filter Expressions in the CLI 

To add a filter to the CLI, use the command: 

SGOS# pcap filter expr parameters 

To remove a filter, use the command: 

SGOS# pcap filter <enter> 



Important: Define CLI filter expr parameters with double-quotes to avoid confusion with 
special 

characters. For example, a space is interpreted by the CLI as an additional parameter, 
but 

the CLI accepts only one parameter for the filter expression. Enclosing the entire 
filter 

expression in quotations allows multiple spaces in the filter expression. 



Configuring Packet Capturing 

Use the following procedures to configure packet capturing. If a download of the captured packets is 
requested, packet capturing is implicitly stopped. In addition to starting and stopping packet capture, 
a filter expression can be configured to control which packets are captured. For information on 
configuring a PCAP filter, see "Common PCAP Filter Expressions" above. 



Note: Requesting a packet capture download stops packet capturing. 

To analyze captured packet data, you must have a tool that reads Packet Sniffer Pro 1.1 
files (for example. Ethereal or Packet Sniffer Pro 3.0). 



To Enable, Stop, and Download Packet Captures through the Management Console 
1. Select Maintenance>Service lnformation>Packet Captures. 
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Packet Captures 

- Packet Captures 

Start capture ~] Stop capture 

Show statistics 

Capture filter: 

D] Include | Q J Kbytes of packets in core 

□ Capture bridging packets 

Packets to capture: @ Capture a) | ma t ch j ng 

o Capture first | 0 | matching 

o Capture last | 0 | matching 





Apply 


_JL_ 


Cancel 


_JL_ 


Help 



Figure E-1 1 : Packet Captures Tab 



2. To configure packet capturing, complete the following steps: 

• To define or change the PCAP filter, enter the filter information into the Capture filter field. (See 
"Common PCAP Filter Expressions" on page 1131 for information about PCAP filter 
expressions for this field.) To remove the filter, clear this field. 

• To specify the number of kilobytes to capture, select Include packets in core and enter a number. 
You can capture packets and include them along with a core image. This is extremely useful if 
a certain pattern of packets causes the unit to restart unexpectedly. 

• To capture all packets, even those that are bridged, select Capture bridging packets. Normally, 
the packets that are bridged from one interface to another (see xxxxx) are not included in the 
packet capture. 

3. Choose one of the following three radio buttons: 

• Capture all matching packets 

• Capture first n matching packets. Enter the number of matching packets (n) to capture. If the 
number of packets reaches this limit, packet capturing stops automatically. 

• Capture last n matching packets. Enter the number of matching packets (n) to capture. Any 
packet received after the memory limit is reached results in the discarding of the oldest saved 
packet prior to saving the new packet. The saved packets in memory are written to disk when 
the capture is stopped. 

4. Click Apply. 

5. To start the capture, click the Start capture button. This button is grayed out if a packet capture is 

already started. 

6. To stop the capture, click the Stop capture button. This button is grayed out if a packet capture is 

already stopped. 
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7. To download the capture, click the Download capture button. This button is grayed out if no file is 
available for downloading. 

To Define Packet Capturing Settings through the CLI 

1. To define PCAP filter parameters, enter the following command at the enable command prompt: 
SGOS# pcap filter parameters 

This captures packets according to the parameters set. If no parameters are set, all packets are 
captured until the pcap stop command is issued. 

See "Using Filter Expressions in the CLI" on page 1132 for information about CLI filter 
parameters. 

2. To begin capturing packets, enter the following command at the enable command prompt: 

SGOS# pcap start {first number | last number | capsize number ( kilobytes ) 
trunc number} 

where: 



• first number allows you to enter the number of matching packets (number) to capture. 
Any 

packet received after the memory limit is reached results in the discarding of the oldest 
saved 

packet prior to saving the new packet. The saved packets in memory are written to disk 
when 

the capture is stopped. 

• last number allows you to enter the number of matching packets ( number ) to capture. 
Any 

packet received after the memory limit is reached results in the discarding of the oldest 
saved 

packet prior to saving the new packet. The saved packets in memory are written to disk 
when 

the capture is stopped. The last and first options supersede each other. 

• capsize number (kilobytes) allows you to stop the collection after number kilobytes (up 
to 

100 MB) of packets have been captured. This command prevents packet capturing from 
taking 

up too much memory and degrading performance. If no parameter is specified, the 
default is 

to capture packets until the stop directive is issued. 

• trunc number allows collecting, at most, number bytes of packets from each frame. 



To Enable, Stop, and Download Packet Captures through a Browser 

1 . Start your Web browser. 

2. Enter the URL: https : / /Proxy SG_lP_address : 8 0 82/PCAP/Statistics and log on to the 
ProxySG as needed. 

The Packet Capture Web page opens. 
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3 Packet Capture - Microsoft Internet Explorer 



File Edit View Favorites Tools Help 






Address | https://10.25.36.47: 8082/PCAP/Statista ^ 



O 

i^Go J 



Packet Capture 

Packet capture Statistics 

Current state: Stopped 
Filtering: On 
Filter expression: 



Packets captured : 56 
Bytes captured : 5,695 
Packets written : 56 
Bytes written : 7,391 
Packets filtered : 0 

Max packet RAM : 0(null) Packet RAM used : 0(null) 
Start packet capture 
Stop packet capture 
Download packet capture file 






zi 



it} Done [Jj £ Internet 

Figure E-12: Packet Capture Web Page 

3. Select the desired action: Start packet capture. Stop packet capture. Download packet capture file. 



You can also use the following URLs to configure these individually: 

□ To enable packet capturing, use this URL: 

https : //ProxySG_ IP_address : 8082/PCAP/start 

□ To stop packet capturing, use this URL: 

https : / /FroxySG_IP_address : 8082/PCAP/stop 

□ To download packet capturing data, use this URL: 

https : //ProxySG_ IP_address : 8082/PCAP/bluecoat . cap 



Viewing Current Packet Capture Data 

Use the following procedures to display current capture information from the ProxySG. 

To View Current Packet Capture Data through the Management Console 

1. Select Maintenance>Service lnformation>Packet Captures. 

2. To view the packet capture statistics, click the Show statistics button. 

A window opens displaying the statistics on the current packet capture settings. Close the 
window when you are finished viewing the statistics. 
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To View Current Packet Capture Data through the CLI 

At the enable command prompt, enter the following command: 

SGOS# pcap info 

packet capture information: 

Packets captured: 12 

Bytes captured: 1879 

Packets written: 12 

Bytes written: 2343 

Max packet ram: 16384 

Packet ram used: 2167 

Packets filtered: 405 

Bridge capture all : Disabled 

Current state: Stopped 

Filtering: On 

Filter expression: iface out expr "" 

Uploading Packet Capture Data 

Use the following steps to transfer packet capture data from the ProxySG to an FTP site through the 
CLI. You cannot use the Management Console. After uploading is complete, you can analyze the 
packet capture data. 

To Upload Packet Captures to a Server through the CLI 

At the enable command prompt, enter the following command: 

SGOS# pcap transfer ftp : //url/path/f ilename . cap username password 

Specify a username and password, if the FTP server requires these. The username and password 
must be recognized by the FTP server. 

Core Image Restart Options 

This option specifies how much detail is logged to disk when a system is restarted. Although this 
information is not visible to the ProxySG user. Blue Coat Technical Support uses it in resolving system 
problems. The more detail logged, the longer it takes the ProxySG to restart. There are three options: 

□ None — no system state information is logged. Not recommended. 

□ Context only — the state of active processes is logged to disk. This is the default. 

□ Full — A complete dump is logged to disk. Use only when asked to do so by Blue Coat Technical 
Support. 

The default setting of Context only is the optimum balance between restart speed and the information 
needs of Blue Coat Technical Support in helping to resolve a system problem. 

You can also select the number of core images that are retained. The default value is 2; the range is 
between 1 and 10. 

To Configure Core Image Restart Options through the Management Console 
1. Select Maintenance>Core Images. 
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Figure E-13: Configuring Core Image Restart Options 



2. Select a core image restart option. 

3. (Optional) Select the number of core images that are retained from the Number of stored images 
drop-down list. 

4. Click Apply. 

To Configure Core Image Restart Options through the CLI 

1. At the (config) command prompt, enter the following command: 

SGOS# (config) restart core-image {context | full | none} 

2. (Optional) To select the number of core images that are retained, enter the following command: 
SGOS# (config) restart core-image keep number 

Diagnostic Reporting (Heartbeats) 

The ProxySG diagnostic reporting configurations are located in the Management Console (under the 
Maintenance>Hearbeats tab), and in the CLI (under the configuration diagnostics submode). 

The daily heartbeat is a periodic message that is sent every 24 hours and contains ProxySG statistical 
data. Besides telling the recipient that the device is alive, heartbeats also are an indicator of the 
ProxySG Appliance's health. Heartbeats do not contain any private information; they contain only 
aggregate statistics that can be use to preemptively diagnose support issues. The daily heartbeat is 
encrypted and transferred to Blue Coat using HTTPS. Administrators can have the daily heartbeat 
messages e-mailed to them by configuring event log notification. The content that is e-mailed to the 
administrator is the same content sent to Blue Coat. For more information about e-mail notification, 
see "Enabling Event Notification" on page 953. 
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If Blue Coat monitoring is enabled. Blue Coat receives encrypted information over HTTPS whenever 
the ProxySG is rebooted. The information does not contain any private information; it contains restart 
summary information, in addition to daily heartbeat information. This allows the tracking of ProxySG 
unexpected restarts due to system issues, and allows Blue Coat to address system issues preemptively. 

If the daily heartbeats setting is disabled, you can still send a heartbeat message by using the 
send-heartbeat command through the CLI (this feature is not available through the Management 
Console). 

To Set Daily Heartbeats and/or Blue Coat Monitoring through the Management Console 
1. Select Maintenance>Heartbeats. 



Heartbeats 

- Monitoring: 

0 Enable daily heartbeats 
0 Enable Blue Coat Systems monitoring 





Apply 


II 


Cancel 


in 


Help 



Figure E-14: Maintenance Heartbeats Tab 

2. Select or deselect Enable daily heartbeats or Enable Blue Coat monitoring. 

3. Click Apply. 

To Set Daily Heartbeats through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) diagnostics 

SGOS# (config diagnostics) heartbeat enable 

To Set Blue Coat Monitoring through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) diagnostics 

SGOS# (config diagnostics) monitor enable 

To Send an Immediate Heartbeat Message through the CLI 

At the (config) command prompt, enter the following command: 

SGOS# (config) diagnostics 

SGOS# (config diagnostics) send-heartbeat 
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Note: This option is not available through the Management Console. 



Diagnostic Reporting (CPU Monitoring) 

You can enable CPU monitoring whenever you want to see the percentage of CPU being used by 
specific functional groups. For example, if you look at the CPU consumption and notice that 
compression/ decompression is consuming most of the CPU, you can change your policy to 
compress/ decompress more selectively. 



Note: CPU monitoring uses about 2-3% CPU when enabled, and so is disabled by default. 



To Configure and View CPU Monitoring through the Management Console 
1. Select Statistics>Advanced. 

A list of links to advanced statistic URLs displays. 



^ General 
System Usage 
•* HTTP/FTP History 
IM History 
P2P History 
^ Streaming History 
■» SOCKS History 
Shell History 
Resources 
Efficiency 
^ Contents 
■* Event Logging 
■> Bandwidth Mgmt. 
•> Access Logging 
■> Failover 
!fe. Advanced 



Statistics 



ADP 

Access Log 
Archive Configuration 
Authentication 
Bridge 

Cache Engine 
Content Filter Service 
DNS 

Diagnostics 

Event log 

Exceptions 

External-services 

FTP 

Failover 

Forwarding 

HTTP 

Health Checks 
ICP 



Figure E-15: Advanced Statistics Tab 
2. Click the Diagnostics link. 

A list of links to Diagnostic URLs displays. 



Diagnostics 



• Show saved snapshots 

/ Diagnostics/Snapshot/[<snapshot name>l/download\/view 
{/aty<report>]jj 

• CPU Monitor statistics 

• Stop the CPU Monitor 

• Start the CPU Monitor 

• Show information about the hardware installed 



Figure E-16: Diagnostic URL Links in the Advanced Statistics Tab 
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3. To enable CPU monitoring, click the Start the CPU Monitor link; to disable it, click the Stop the CPU 
Monitor link. 

4. To view CPU monitoring statistics, click the CPU Monitor statistics link. You can also click this 
link from either of the windows described in step 3. 

To Configure and View CPU Monitoring through the CLI 

1. To enable or disable CPU monitoring, enter the following commands at the (conf ig) command 
prompt: 

SGOS# (config) diagnostics 

SGOS# (config diagnostics) cpu-monitor {enable | disable} 

2. To set the interval between CPU monitoring, enter the following command: 

SGOS# (config diagnostics) cpu-monitor interval seconds 

where seconds is a number from 1 to 59 that sets the frequency (in seconds) that the CPU 
monitor statistics are updated. 

3. To view CPU monitoring results, enter the following command: 

SGOS# (config diagnostics) view cpu-monitor 
CPU Monitor: 

Configured interval duration: 5 seconds 

Current interval complete in: 3 seconds 

CPU 036% 

HTTP and FTP19% 

Object Storel5% 

Miscellaneousl% 

CPU 118% 

TCPIP15% 

HTTP and FTP3% 

If the CPU monitor is disabled, the view command display the following message: 

SGOS# (config diagnostics) view cpu-monitor 

CPU Monitor is not running. Enable in diagnostics menu 



Note: The total percentages do not always add up because the display only shows those 

functional groups that are using 1% or more of the CPU processing cycles. 

The commands SGOS#(config) show cpu and SGOS# (config diagnostics) view 
cpu-monitor can sometimes display CPU statistics that differ by about 2-3%. This occurs 
because different measurement techniques are used for the two displays. 
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Blue Coat Director allows you to manage multiple ProxySG Appliances as opposed to configuring and 
controlling the appliances individually. 

Director allows you to configure a ProxySG and then push that configuration out to as many ProxySG 
Appliances as required. Director also allows you to delegate network and content control to multiple 
administrators and distribute user and content policy across a Content Delivery Network (CDN). With 
Director, you can: 

□ Reduce management costs by centrally managing all Blue Coat ProxySG Appliances, 
n Eliminate the need to manually configure each remote ProxySG. 

□ Recover from system problems with configuration snapshots and recovery. 

Configuration management specifically includes: 

□ Configure groups of ProxySG Appliances based on locations, applications, or other factors. 

□ Delegate ProxySG administration by access level, group, or policy. 

□ Rapidly deploy standardized configurations using profiles. 

□ Manage the scheduling of policy and configuration changes. 

□ Easily schedule incremental changes to one or more ProxySG Appliances, 
n Create and distribute policy across a system of ProxySG Appliances. 

□ Automatically back up configuration snapshots. 

□ Back up ProxySG backup files. 

n Compare backup files from different ProxySG Appliances. 

□ Restore configuration backups to multiple ProxySG Appliances. 

□ Automatically distribute software licenses. 

D Quickly monitor ProxySG status, statistics, and configurations. 

O Upgrade an entire content-smart network at once. 

How Director Works with ProxySG 

Director consists of a management node (a domain) and the ProxySG Appliances that you want to 
manage. The appliances can be added to the domain through either Director's CLI or Management 
Console. 
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Note: Do not mix ProxySG versions within a domain; errors might result if you try to push the 

same configuration to machines that are running different versions of SGOS. 



When a ProxySG is added to the domain, you provide connection information about the ProxySG: 
name (meaningful to you), IP address or full hostname, username/password, authentication method 
and credentials, and, optionally, a description. 

Only the appliances added to the domain can be managed by the domain. Multiple domains can be 
created. 

Once added to the domain, you can manage the ProxySG either individually, through the Quick 
View/Edit module, or you can manage multiple appliances through the Configuration Management 
module. 




Figure F-1 : Director Management Console 



Communication Between Director and the ProxySG 

Director and the ProxySG use SSHv2 as the default communication mode. To use SSHvl or Telnet, 
you must do additional configuration on the ProxySG. 

For Director to successfully manage multiple ProxySG Appliances, it must be able to communicate 
with a ProxySG using SSH/RSA and the Director's public key must be put on each ProxySG that 
Director manages. This creates a golden profile, meaning that the ProxySG is fully authenticated and 
can be used to push configurations to multiple ProxySGs using the same version of the software. 

At initial set up of the ProxySG on Director, Director connects to the device using the authentication 
method established on the device: Telnet, SSH with simple authentication, or SSH/RSA. SSH/RSA is 
preferred, and must also be set up on Director before connecting to the ProxySG. 



Note: You cannot connect to a ProxySG using Telnet without first enabling the Telnet-Console 

on the ProxySG. 
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Director can create an RSA keypair for a ProxySG to allow connections. However, for full functionality. 
Director's public key must be put on each ProxySG. You can put the key on the ProxySG two ways: 

□ Use Director to create and push the key. 

□ Use the import-director-client-key CLI command from the ProxySG. 

Using Director to create and push client keys is the recommended method. The CLI command is 
provided for reference. 

Complete the following steps to put Director's public key on the ProxySG using the CLI of the 
ProxySG. You must complete this procedure from the CLI. The Management Console is not available. 



Note: For information on creating and pushing a SSH keypair on Director, refer to the Blue Coat 

Director Installation Guide. 



Login to the ProxySG you want to manage from Director. 

1. From the (config) prompt, enter the services>ssh-console submode: 

SGOS# (config) services 

SGOS# (config services) ssh-console 

SGOS# (config services ssh-console) 

2. Import Director's key that was previously created on Director and copied to the clipboard. 



Important: You must add the Director identification at the of the client key. The example shows 

the username, IP address, and MAC address of Director. "Director" (without quotes) 
must be the username, allowing you access to passwords in clear text. 



SGOS# (config services ssh-console) import director-client-key 
Paste client key here, end with "..." (three periods) 
ssh-rsa 

AAAAB3NzaClyc2EAAAABIwAAAIEAvJIXtlZausE9qrcXem2IK/mC4dY8Cxxol/B8th4KvedFY330 
ByO/pvwcuchPZz+blLETTY/zc3SL7jdVffq00KBN/ir4zu7L2XT68ML20RWa9tXFedNmKl/iagI3 
/QZJ8T8zQM6o7WnBzTvMC/ZElMZZddAE3yPCv9+s2TR/Ipk=director@10 .25.36.47-2. OOeO . 
8105. d46b 

ok 

To View the Fingerprint of the Key 

SGOS# (config sshd) view director-client-key clientID 

jsmith@granite.example.com 83:C0:0D:57:CC:24:36:09:C3:42:B7:86:35:AC:D6:47 

To Delete a Key 

SGOS# (config sshd) delete director-client-key clientID 
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Importing VPM Policy 

If you have your VPM policy stored locally and want to install it on a ProxySG, you can use SGOS 
inline commands to install them directly on the system. VPM policy is stored in two files, vpm-cpl and 
vpm-xml. You must install both of them. (For more information on using VPM, see Chapter 14: "The 
Visual Policy Manager" on page 567.) 



Note: VPM files are generally pulled from a specified ProxySG (reference device) and 

distributed to other ProxySG Appliances through the Director Management Console, and 
this is the recommended method. The procedure below is provided for reference. 

For information on using VPM files with Director, refer to the Blue Coat Director User 
Guide. 



Before you begin, copy the policy you are installing to the clipboard. 

From the (config) prompt, enter the following commands: 

SGOS# (config) inline policy vpm-cpl eof 

< Proxy > 

Deny url . domain= " restricted" ; Rule 1 eof 
ok 



where eof is the string you use to indicate to the system that you are beginning or ending. It 
can be any string of letters, but it should not be a string you type as part of the policy. 

SGOS# (config) inline policy vpm-xml eof 

<vpmapp> 

<conditionObj ects> 

destination-url name="URLl" port="-l" single= " true " url= " restricted" /> 
</conditionObj ects> 

<layers> 

< layer layertype= "com . bluecoat . sgos . vpm . WebAccessPolicyTable " > 

<name>Web Access Policy (1) </name> 

< numRows > 1 < / numRows > 



<rowItem 


enabled; 


="true" num= 


" 0 " > 




<colItem 


col=' 


0" 


value="l" / 


> 




<colItem 


col=' 


1" 


name= "Any" 


type= " String" 


/ > 


<colItem 


col=' 


2" 


name= "URL1 " 


negate= " false 


" type 


<colItem 


col=' 


3" 


name= "Any" 


type= " String" 


/> 


<colItem 


col=' 


4" 


name= "Deny" 


type=" String" 


/> 


<colItem 


col=' 


5" 


name= "Any" 


type= " String" 


/> 


<col!tem 


col=' 


6" 


name="" type="String" /> 





< / rowItem> 

</layer> 

</layers> 

< / vpmapp > 
eof 
ok 
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Backing Up a Proxy SGs SSL Settings 

You can return to a previous ProxySG configuration by using a backup (a snapshot of the appliance at 
a point in time). Backups are either created explicitly by request or automatically prior to each profile 
push. They are stored on Director. 

Backup configurations consist of specific configuration parameters related to a particular ProxySG. A 
backup saves all configuration settings. You can also back up SSL settings, including keyrings, 
CA-certificates, external-certificates, certificate signing-requests, certificate-lists, and cipher suites 
used. 

When pushing a profile to another ProxySG, the SSL configuration needs to be pushed to the ProxySG 
before any other configuration is pushed to ensure that the required SSL keyrings are available for 
setting up the services. 

Creating Profiles 

A profile is a snapshot of a ProxySG configuration that can be used as a template to configure other 
ProxySGs. 

When Director uses a profile, it takes the output of the ProxySG show configuration command from 
one system ( creating the profile) and applies that configuration to the ProxySG appliances you specify 
( pushing the profile). 



Note: Because the show configuration output is specific to one type of system, it is important 

to push profiles only to ProxySGs with similar platforms and versions. 

It is also important to be sure that profile comes from a fully-authenticated ProxySG; that 
is, one that it is fully authenticated through SSH/RSA. Such systems are said to have 
golden profiles, profiles without invalid commands for other devices using the same SGOS 
version. 



If the configuration does not display in the show configuration output, it is not pushed to other 
systems as part of a profile. Specifically, keyrings configured with the no-show option are not part of 
the show configuration output. (Keyrings configured with the show-director option are part of the 
output only if Director is issues the command using SSH-RSA.) 

You can manipulate the show configuration output by 

□ creating configurations on different systems to provide profiles for different purposes. 

□ using the restore-defaults keep-console command: Restore to the factory defaults, restore to 
the factory defaults but keep the configured secure consoles 

For more information on using the restore-defaults command, see "Restoring System Defaults" 
on page 941. 

When a profile is created SSL configuration settings, such as self-signed certificates and certificate 
signing requests, are included if they were created with the non-interactive or inline form of the SSL 
commands. The interactive form of the SSL commands is never permitted in within a profile or 
overlay. (For information on using non-interactive SSL commands, see Chapter 7: "Using Secure 
Services" on page 265.) 



1145 



Blue Coat Proxy SG Configuration and Management Guide 



For more information on using profiles, refer to Chapter 5, "Configuration Management," in the Blue 
Coat Director User Guide. 

Creating Overlays 

An overlay is one or more individual settings (such as time, SNMP, bandwidth gain, or SSL settings) 
that can be can be applied to one or a selected set of ProxySGs. An overlay is overlaid on a profile, 
changing specific settings created by the profile to fine-tune configuration specifics without having to 
create new profiles. 

SSL configuration settings, such as self-signed certificates and certificate signing requests, must be 
created using the non-interactive commands to be used in Director overlays. To use SSL 
non-interactive settings: 

□ "To Create a Self-Signed SSL Certificate Non-interactively Using Create Commands" on page 283 

□ "To Create a Signing Request Non-interactively Using Create Commands" on page 278 

□ "To Change the Cipher Suite of the SSL Client through the CLI" on page 293 

SSL values can also be created using the SSL inline commands and can be used in overlays: 

□ "Importing an External Certificate" on page 910 

□ "To Import a CA Certificate through the CLI Using Inline Commands" on page 305 

For more information on using overlays, refer to Chapter 5, "Configuration Management," in the Blue 
Coat Director User Guide. 

Director Documentation 

The following documentation is available: 

□ Blue Coat Director Installation Guide 
n Blue Coat Director User Guide 

n Blue Coat Director Content Sync Modide Guide 

□ Blue Coat Director Request Management Guide 

Blue Coat Director documentation can be found at 

http : / / download.bluecoat.com / release / SGME / index.html 
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The XML realm uses a SOAP 1.2 based protocol for the Blue Coat supported protocol. A schema has been 
placed at http:/ /www.b luecoat.com/xmlns/xml-realm/ 1.0. 
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Section A: Authenticate Request 

Section A: Authenticate Request 
GET Method (User Credentials in Request) 

If the user credentials are not set in the HTTP headers, the username and password are added to the query. 
The name of the username parameter is configured in the realm. The groups and attributes of interest are only 
included if the realm is configured to include them. 

http : //<server hostname> : <server port>/<authenticate service path>?<username parameter 
name>=<username>&password=<password> [&group=< group l>&group=< group 2>...&attribute=<attribute 
!>&attribute=<attribute 2>] 

GET Method (User Credentials in Headers) 

If the user credentials are in the HTTP headers, the password is not added to the query. 

http : //<server hostname> : <server port>/<authenticate service path>/authenticate?<username 
parameter name> = <username> [&group=<group l>&group=<group 2>...&attribute=<attribute 
!>&attribute=<attribute 2>] 

POST Method (User Credentials in Request) 

The parameter name of the username is configured in the realm. The groups and attributes of interest will only 
be included if the realm is configured to include them. 

<?xml version= ' 1 . 0 1 encoding="UTF-8" ?> 

<env : Envelope 

xmlns : env= "http : //www . w3 . org/20 03 /05/soap-envelope" > 

<env : Body env: encodings tyle= "http : / /www . w3 . org/20 03 /05/soap-encoding" 
xmlns : enc= "http : / /www. w3 . org/2003 /05/ soap -encoding" > 

<m: authenticate 

xmlns :m= "http : / /www. bluecoat . com/xmlns /xml- realm/ 1 . 0 " > 

<m:username>Username</m:username> 

<m: password>password</m : password> 

<m:groups enc : arraySize=" * " enc : itemType="xsd : string" > 

<m : group >groupl < /m : group > 

<m : group >group2 < /m : group > 

</m : groups > 

<m: attributes enc : arraySize=" * " enc : itemType="xsd : string" > 

<m: attribute>attributel</m: attribute> 

<m: attribute>attribute2</m: attribute> 

</m : attributes> 

</m: authenticate> 

</env: Body> 

</env : Envelope> 

POST Method (User Credentials in Headers) 

If the user credentials are in the HTTP headers, the password is not added to the request. 
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Section A: Authenticate Request 



<?xml version= ' 1 . 0 1 encoding="UTF-8 " ?> 

<env : Envelope 

xmlns : env="http : //www . w3 . org/20 03 /05/soap-envelope" > 

<env : Body 

env : encodings tyle= "http : / /www. w3 . org/2 003/05/soap-encoding" > 
<m: authenticate 

xmlns :m= "http : / /www . bluecoat . com/xmlns /xml- realm/ 1 . 0 " > 

<m : username>Username< /m : username > 

<m: challenge-state>challenge state</m: challenge-states 
<m:groups enc : arraySize=" * " enc : itemType="xsd : string" > 

<m : group sgroupl < /m : group > 

<m : group >group2 < /m : group > 

</m : groups > 

<m: attributes enc : arraySize=" * " enc : itemType="xsd : string" > 
<m: attribute>attributel</m: attributes 
<m: attributesattribute2</m: attributes 
</m : attributess 
</m: authenticates 
</env: Bodys 
</env : Envelopes 
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Section B: Authenticate Response 



Section B: Authenticate Response 
Success 

All of the response fields except "full-username" are optional. The intersection of the groups of interest and the 
groups that the user is in are returned in the groups element. The attributes of interest for the user are returned 
in a flattened two dimensional array of attribute names and values. 

<?xml version= ' 1 . 0 1 encoding="UTF-8 " ?> 

<env : Envelope 

xmlns : env= "http : //www . w3 . org/20 03 /05/soap-envelope" > 

<env : Body 

env : encodings tyle= "http : / /www. w3 . org/2 003/05/soap-encoding" > 

<m: authenticate-response 

xmlns :m= "http : / /www. bluecoat . com/xmlns /xml- realm/ 1 . 0 " > 

<m: f ul 1 -username > f ul 1 -username</m: full -username > 

<m:groups enc : arraySize=" * " enc : itemType="xsd : string" > 

<m : group >group2 < /m : group > 

</m : groups > 

<m: attribute-values enc : arraySize= " * 2" enc : itemType="xsd : string" > 

<m: item>attribute2</m : item> 

<m: item>value2a</m: item> 

<m: item>attribute2</m: item> 

<m: item>value2b</m: item> 

<m: item>attribute2</m : item> 

<m: item>value2c</m : item> 

</m : at tribute- values > 

</m: authenticate-response> 

</env: Body> 

</env : Envelope> 



Failed/Denied 



The failed response includes a text description of the failure that becomes the text description of the error 
reported to the user. The fault-code is one of a set of SGOS authentication errors that can be returned from the 
responder. The codes are returned as strings, but are part of an enumeration declared in the schema for the 
protocol. Only codes in this list are acceptable. 



account_disabled 

account_restricted 

credentials_mismatch 

general_authentication_error 

expired_credentials 

account_locked_out 

account_must_change_password 

offbox_server_down 

general_authorization_error 

unknown_error 
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Section B: Authenticate Response 



<?xml version= ' 1 . 0 1 encoding="UTF-8 " ?> 

<env : Envelope 

xmlns : env="http : //www . w3 . org/20 03 /05/soap-envelope" > 

<env : Body> 

<env: Fault> 

<env : Code> 

<env: Value >env : Sender </env : Value > 

</env: Code> 

<env : Reasons 

<env : Text xml : lang="en-US" >Bad username or password< / env : Text > 
</env : Reasons 
<env : Details 
<e : realm- fault 

xmlns : e= "http : //www . bluecoat . com/xmlns /xml- realm/ 1 . 0 " s 

<e : f ault-codesgeneral_authentication_error< /e : fault -codes 
<e : realm- faults 
<env : Details 
<env : Faults 
</env: Bodys 
</env : Envelopes 
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Section C: Authorize Request 

Section C: Authorize Request 

The groups and attributes of interest for the user are embedded in the request if they are configured to be 
included. The XML responder must not require credentials for authorization requests. 

GET Method 

http : //<server hostname> : <server port>/<authorize service path>?<username parameter 
name> = <username> [&group=<groupl>&:group=<group2>...&attribute = <attributel >&...] 



POST Method 

<?xml version= ' 1 . 0 1 encoding="UTF-8 " ?> 

<env : Envelope 

xmlns : env="http : //www . w3 . org/20 03 /05/soap-envelope" > 

<env : Body 

env : encodings tyle= "http : / /www. w3 . org/2003 /05/ soap -encoding" 
xmlns : enc= "http : / /www. w3 . org/2 003/05/soap-encoding" > 

<m: authorize 

xmlns :m= "http : / /www . bluecoat . com/ soap /xmlns /xml -realm/ 1 . 0 " > 
<m : username>Username< /m : username > 

<m:groups enc : arraySize=" * " enc : itemType="xsd : string" > 

<m : group >groupl < /m : group > 

<m : group >group2 < /m : group > 

< /m: groups > 

<m: attributes enc : arraySize=" * " enc : itemType="xsd : string" > 
<m: attribute>attributel</m: attribute> 

<m: attribute>attribute2</m: attribute> 

</m : attributes> 

</m: authorizes 
</env: Body> 

</env : Envelopes 
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Section D: Authorize Response 



Section D: Authorize Response 
Success 

Only applicable groups and attributes are returned. Multi-valued attributes are returned by multiple instances 
of the same attribute name. 

<?xml version= ' 1 . 0 1 encoding="UTF-8 " ?> 

<env : Envelope 

xmlns : env="http : //www . w3 . org/20 03 /05/soap-envelope" > 

<env : Body 

env : encodings tyle= "http : / /www. w3 . org/2 003/05/soap-encoding" 
xmlns : enc= "http : / /www. w3 . org/2 003 /05/soap-encoding" > 

<m: authorize-response 

xmlns :m= "http : / /www. bluecoat . com/xmlns /xml- realm/ 1 . 0 " > 

<m:groups enc : arraySize=" * " enc : itemType="xsd : string" > 

<m : group >group2 < /m : group > 

</m : groups > 

<m: attribute-values enc : arraySize= " * 2" enc : itemType="xsd : string" > 

<m: item>attribute2</m : item> 

<m: item>value2a</m: item> 

<m: item>attribute2</m : item> 

<m: item>value2b</m: item> 

<m: item>attribute2</m : item> 

<m: item>value2c</m: item> 

</m : at tribute- values > 

</m: authorize> 

</env: Body> 

</env : Envelope> 



Failed 

<?xml version= ' 1 . 0 1 encoding= "UTF- 8 " ?> 

<env : Envelope 

xmlns : env="http : //www . w3 . org/20 03 /05/soap-envelope " > 

<env : Body> 

<env : Fault> 

<env : Code> 

<env : Value >env : Receiver < / env : Value > 

</env : Code> 

<env : Reasons 

<env : Text xml : lang="en-US" sCould not contact LDAP server</env:Text> 
</env : Reasons 
<env : Details 
<e : realm- fault 

xmlns : e= "http : //www . bluecoat . com/xmlns /xml- realm/ 1 . 0 " s 
<e : f ault-codesof fbox_server_down</e : fault-codes 
<e : realm- faults 
<env : Details 
<env : Faults 
</env: Bodys 
< / env : Enve lopes 
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tolerant request parsing 199 
HTTP client compression object, using in VPM 214 
HTTP Console 
commands 156 
managing through CLI 156 
managing through Management Console 156 
HTTP port service 

CLI commands 169, 240, 262 
creating 168 
HTTP proxy 
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bandwidth gain 208 

bandwidth gain profile 201 

byte-range support 208 

compression 211 

compression behavior 212 

compression boundary conditions 219 

compression, configuring 214 

normal profile 201 

portal profile 201 

profile settings, configuring 206 



profile settings, explained 202 
range request types 209 
revalidate pragma-no-cache 210 
traffic, controlling 200 
viewing settings 210 
HTTP redirection 

multicast address example 1108 
multicast address router configuration 1108 
password example 1109 
ProxySG configuration 1108 
ProxySG multicast address configuration 1108 
ProxySG password example 1109 
router configuration example 1108 
router configuration for password 1109 
HTTP server 

XML realms, configuring for 447 
HTTP server compression object, using in VPM 214 
HTTP upload client, configuring 922 
HTTPS 

content filtering, using with 839 
content scanning 513 
origination 297 
tunneled connection 708, 730 
HTTPS Console 

certificate error message 290 
creating through CLI 153, 183 
enabling 153, 183 
IP address, selecting 153 
keyring, selecting 153, 183 
managing through CLI 155 
managing through Management Console 153 
port service, creating 156 
troubleshooting certificate problems 290 
HTTPS port service 
commands 171 
creating 169 
HTTPS termination 
certificates 266 
client map 269 
configuring 270 
keyring, creating 271 
offloading SSL processing 266 
HTTPS traffic, intercepting 238 

I 

ICAP 

access logging 532 
configuring the ProxySG for 515 
content scanning 513 
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installing 515 
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patience pages 517 
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refreshing content versions 515 
sense settings 512 
Symantec CarrierScan Server 512 
Trend Micro InterScan Virus Wall 512 
WebWasher 512 
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configuring 148 
ICMP error message 

ICMP host unreachable 149 
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configuring 148 
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creating an installable list for 876 
enabling through CPL 881 
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restricting access 878 
identification (Ident) protocol 874 
i-FILTER 

configuring through CLI 806 
configuring through Management Console 804 
imputing 

adding names through CLI 113 
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changing name order 113 
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see also DNS 110 
understanding 113 
inbound connections, rejecting 88 
inline commands 

creating policy with 556, 559 
Director, using 1144 
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482 
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ICP 876 



SOCKS 871 
instant messaging 

access log format 892 

AOL Messenger client configuration 780 

configuring clients 779, 795 

configuring proxies 776 

creating 172 

defined 33 

MSN Messenger client configuration 781 
protocol policies 769 
proxy authentication 774 
securing 769 

statistics, IM data tab 986 
VPM 782 

Yahoo Messenger client configuration 779 
interface cards, configuring through CLI 185 
Internet Explorer, explicit proxy, using with 220 
Internet Explorer, troubleshooting for explicit policy 
substitution realm 472 

Internet Explorer, troubleshooting for transparent 
proxy 472 

Internet Explorer, versions supported 36 
InterSafe 

configuring through CLI 809, 811 
configuring through Management Console 807 
IP address, configuring through CLI 87 
IP forwarding, enabling through Management 
Console 261 

issuer certificates, downloading for desktops 243 
IWA 

configuring authentication and authorization 341 
creating a realm through CLI 343 
defining realm server properties 342 
defining realm server properties through 
Management Console 342 
Kerberos, enabling 346 
overview 341 

Service Principal Names, creating 1031 
IWF 

configuring through Management Console 810 

J 

JavaScript 709 
JREs 

supported 36 

K 

Kerberos. See IWA 
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associating with certificate through CLI 301 

commands, create 274 

creating through CLI 274 

creating through Management Console 272 

importing through Management Console 300 

SSL client, associating 292 

view command 275 

L 

LDAP 367 

authentication and authorization overview 360 
authorization 369 
case-sensitive configuration 363 
certificate realm, adding to 413 
CPL examples 375 
defining Base DNs through CLI 368 
defining Base DNs through Management Console 
367 

defining realm authorization properties and 
group information through Management 
Console 369, 371 

defining realm server properties through CLI 362 
defining realm server properties through 
Management Console 361 
defining server properties through CLI 347 
defining server properties through Management 
Console 362 

editing server properties through CLI 363 
edit-realm commands 364 
group information 370 
membership-attribute command 371 
membership-type command 371 
policy-substitution realm, adding to 463 
search boundaries 370 
searching multiple base DNs 366 
SSL, enabling 363 
v2/v3 support 360 
virtual URL, setting up 374 
LDAP DN 367, 506 
LDAP realm 

results, viewing 365 
licensing 
about 47 
components 47 
expiration 49 
installing 51 

restore-default deletions 941 



trial period 48 
updating 56 
viewing 55 

Lightweight Directory Access Protocol, see LDAP 
link settings 89 
load balancing 

assigning percentages 1099 
gateways 99 
understanding 1098 
using multiple default IP gateways 98 
local bypass 
example 122 
local database 

automatic download 794 
clearing 793 

configuring through CLI 793 
configuring through Management Console 792 
local realm 

authentication and authorization overview 400 
certificate realm, adding to 413 
changing properties 401 
CPL, creating policies 410 
database group, creating 407 
database user, creating 407 
database users, viewing 407 
database, creating 404 
database, creating through ProxySG 406 
database, populated 404 
database, setting up 404 
defining realm server properties through 
Management Console 400 
deleting groups 409 
deleting users 408, 409 
groups, defined 405 
groups, deleting 408 
hashed passwords 405 
policy substitution realm, adding to 463 
results, viewing 403 
user account, enabling 407 
user name, defined 405 
user password, creating 407 
users, deleting 409 
view all lists 408 
virtual URL, setting up 402 
local user list 

security settings, changing 409 
locking and unlocking ProxySG systems 950 
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creating 897 
deleting 902, 951 
editing 899 
log format 
SSL 893 
logging 

event log 1009 

see access logging and event logging 
SNMP 957 

syslog event monitoring 954 
login parameters 61 
logs 

CacheOS 4.x, retrieving 1019 
SGOS 2.x, retrieving 1019 

M 

management architecture, overview 30 
Management Console 
accessing 61 

changing username and passwords in 63 

configuring SSH 68 

console account 63, 64 

home page 61 

HTTP Console 155 

HTTPS Console 152, 182 

importing SSH client keypairs 70 

logging in 61 

logging out 62 

managing 152, 160 

SSH Console 157 

Telnet Console 157, 186 

troubleshooting 945, 981 

max_dynamic_bypass_entry, using with dynamic 
bypass 127 

menu bar in Visual Policy Manager 571, 711 
meta tags 
parsing 199 
MIBs 957 
MMS 

port service, creating 173 
port services MMS commands 172, 173 
modes, understanding 59 
modifying headers 711 
MSN port service, creating 172 
multicast 

D range address, explained 139 



defined 730 

failover, using with 139 
unicast, converting by Windows Media 749 
multicast address 
configuring 1092 
ProxySG configuration 1108 
router configuration 1108 
syntax 1092 

multicast packet reception, enabling 1095 

N 

name imputing, see imputing 
name, configuring 74 

NCSA, common access log format 892, 1046 
negate option, using in Visual Policy Manager 575 
negative caching 

disabling for DNS responses 114 
enabling for DNS responses 114 
netbios 

using with policy substitution realm 464 
Netegrity SiteMinder realm 
agents, configuring 423 
case-sensitive configuration 432 
creating through CLI 423 
creating through Management Console 423 
defining server properties through CLI 430 
display name, changing 432 
making general settings through CLI 432 
policies, creating 433 
protected resource, entering 429 
server mode, configuring 429 
servers, configuring through Management 
Console 426 

servers, editing through CLI 427 
servers, editing through Management Console 
427 

SiteMinder agent, defining through CLI 424 
SSO-only mode, enabling 429 
viewing through CLI 428 
Netscape, versions supported 36 
network adapter 

advanced configuration 88 
configuring through CLI 87 
link faults 89 
link settings 89 

rejecting inbound connections 88 
Network Time Protocol server, see NTP 
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authorization, using 378 
BCAAA, configuring 379 
creating a realm through CLI 381 
defining general properties through CLI 387 
defining realm server properties 379 
defining realm server properties through 
Management Console 379 
general properties, configuring 386 
policies, creating 388 
sso. ini file, modifying 387 
NTLM 

authenticate. mode, setting 325 

explicit proxy, using with Internet Explorer 220 

force authentication 

enabling through CPL 222 
enabling through VPM 222 
Internet Explorer, using with 220 
policies, creating 348 
realm sequence position 471 
single sign-on, configuring 348 
NTLM. See IWA 
NTP 

adding server through CLI 78 

adding server through Management Console 78 

server order, changing 79 

time server, definition of 75 

understanding 77 

o 

object tags 710 
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deleting from ProxySG 971 
in Visual Policy Manager 577 
served 982 
served by size 1008 
one-time passwords 

XML realms, configuring 449 
Optenet content filtering 

configuring through CLI 814 
configuring through Management Console 812 
optional negation syntax, using 1102 
Oracle, See COREid 
origination, HTTPS 297 
origin-style authentication 
origin 323 
origin-cookie 323 
origin-cookie-redirect 323 



origin-ip 323 
origin-ip-redirect 323 
overlays 

settings used in 1146 

P 

P2P 

access log format 892 
access logging 727 
authentication 727 
managing 725, 743 
policy 726 
packet capturing 
about 1130 
capturing 1132 

common filter expressions 1131 
file name format 1131 
uploading data 1136 
viewing current data 1135 
packet redirection 
enabling 1094 
excluding 1095 
password 

changing through CLI 65 
changing through Management Console 63 
default for 63 
hashed, encrypted 312 
HTTP redirection example 1109 
security, understanding 312 
see also privileged-mode password 
with RIP 1120 
patience pages 
displaying 517 
troubleshooting 720 
peer-to-peer 

access logging 727 
authentication 727 
managing 725, 743 
policy 726 

PEM-encoded URLs, CRLs, using with 286 
Permeo 

customer ID, obtaining 227 
PA client, about 227 
PA license, disabling on ProxySG 229 
PA limitations 229 
ProxySG, PA licensing on 228 
PMTU 

enabled by default 149 
overview 149 
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bandwidth management examples 502 
bypass list 126 

changing in Visual Policy Manager 677 
CLI inline command, using 559 
configuring policy evaluation order 556 
configuring the default policy proxy setting 555, 
556 

content scanning 514 
creating through CLI 559 
disabling 560 

disabling in Visual Policy Manager 678 
editing 556 

enabling in Visual Policy Manager 678 

example, limit access to certain Web sites 836 

example, limit access to specified time of day 836 

files loading 556 

files, loading through CLI 560 

for maximum security 314 

for moderate security 314 

inline command 559 

inline commands, using 556 

layers in 675 

loading in Visual Policy Manager 676 
managing bandwidth 500 
overview 30 
policy editor 567 

saving in Visual Policy Manager 676 

source, viewing 564 

source, viewing through CLI 564 

statistics, viewing 565 

tabs for in Visual Policy Manager 573 

tracing 556 

tracing information 565 
unloading 560 

unloading/ disabling files through CLI 561 
vendor categories, using with 836 
viewing through CLI 564 
viewing with browser 563 
Visual Policy Manager 567 
policy evaluation order 

configuring through CLI 554 
configuring through Management Console 554 
policy substitution realm 
configuring 453 

creating a realm through CLI 457 
defining properties through Management 
Console 458 



defining realm server properties through 
Management Console 456 
full usernames, constructing 458 
general properties, defining through CLI 464 
general properties, defining through 
Management Console 463 
header, using with 465 
how it works 453 
LDAP authorization, adding 463 
local authorization, adding 463 
netbios, using with 464 
policies, creating 466 
results, viewing 464 
troubleshooting 472 
user, username fields, explained 454 
usernames, constructing 458 
pop-up ads, blocking 706 
port services 

AOL, Yahoo, MSN, creating 172 
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attributes supported 161 

creating /editing 160 

FTP, creating 166 

FTP, defined 166 

HTTP, creating 168 

HTTPS Console, creating 153, 156, 183 
HTTPS, creating 169 
instant messaging protocols 172 
MMS port services commands 172, 173 
MMS, creating 173 

RTSP port services commands 172, 173 
RTSP, creating 173 
SOCKS, creating 174 
SSH Console, creating 157 
supported 160 
TCP-Tunnel, creating 176 
Telnet Console, creating 158 
Telnet Console, explained 157, 186 
privilege (enabled) mode, understanding 59 
privileged-mode password 
changing through CLI 65 
changing through Management Console 63 
default for 63 
profiles 

show configuration output, using 1145 
prompt, customizing for Telnet 232 
Proventia 

configuring through CLI 816 

configuring through Management Console 815 
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configuring default settings through Management 
Console 555, 556 
definition 181, 309 
explicit, browser settings 184 
explicit, creating 183 
interface settings 184 
setting up 181 

SOCKS, configuring through CLI 225 
SOCKS, configuring through Management 
Console 224 
understanding 181 
Proxy layer 
actions 338 
conditions 330 
properties 336 

proxy server, using ProxySG as 183 
ProxySG 

accessing 60 

browsers supported 36 

configuration file, creating 1102 

configuration file, creating with text editor 1106 

configuration file, loading 1106 

configuration file, quick start 1090 

configuration file, syntax 1102 

configuration file, using CLI 1105 

deleting a system 951, 989 

deleting objects from 971 

DNS server 110 

features 29 

FTP example 1110 

home router IP address, verifying 1112 
HTTP configuration example 1108 
HTTP redirection multicast address example 1108 
HTTP redirection with password example 1109 
ICAP service configuration 515 
instant messaging, AOL Messenger client 
configuration 780 

instant messaging, configuring clients 779, 795 
instant messaging, configuring proxies 776 
instant messaging, IM data tab statistics 986 
instant messaging, MSN Messenger client 
configuration 781 

instant messaging, protocol policies 769 
instant messaging, proxy authentication 774 
instant messaging, securing 769 
instant messaging, VPM 782 
instant messaging, Yahoo Messenger client 
configuration 779 
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load balancing 1099 

locking and unlocking a system 950, 987 
managing 948, 984 
multi-disk 970 

optional negation syntax, using 1102 
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read-only and read-write access 59, 313 
realm name, changing through CLI 66 
realm name, changing through Management 
Console 66, 67 
replacing a system 948, 950 
restarting 939 

reverse proxy example 1110 
serial number, configuring 75 
setting the default system to boot 949 
simultaneous connections to, viewing 119 
single-disk 971, 1008 
subnet mask for 87 
system defaults 941 
time, configuring 75 
timeout, changing through CLI 67 
upgrading 945 
viewing details 948 
WCCP configuration, creating 1097 
WCCP versions supported 1087 
WCCP-known caches, displaying 1107 
ProxySG 

alternate hashing example 1111 
proxy-support header 

disabling through CPL 221 
disabling through VPM 220 
Internet Explorer, using with 220 
purging the DNS cache 944 

Q 

quick start 

ProxySG, creating a configuration file 1090 
WCCP configuration 1089 
QuickTime 

access logging, using with 903 

R 

RADIUS 

authentication and authorization overview 390 
case-sensitive usernames, setting 393 
creating a realm through CLI 394 
defining realm server properties through 
Management Console 390, 392 
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troubleshooting 398 
RADIUS session monitor 
cluster, configuring 143 
configuring 144 
configuring failover group 143 
limitations 146 
range request types 209 
read-only access in ProxySG 59, 313 
read-write access in ProxySG 59, 313 
realm 

COREid, creating 437 
name, changing 66 
timeout, changing 67 
realm banner, Telnet, customizing for 232 
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creating 469 

creating through CLI 470 
managing through CLI 471 
NTLM realm position 471 
promote/ demote member realms 470 
results, viewing through CLI 471 
virtual URL 471 
RealMedia 

access logging, using with 903 
proxy authentication 737 
realms 

COREid 434 

COREid, access server 440 
COREid, agents 
configuring 438 

COREid, configuring general settings 442 
COREid, CPL, crating 444 
definition 310 

promote/ demote for sequence realms 470 
sequence, troubleshooting 467 
understanding 339 
rebooting, see restarting 939 
redirection access list, creating 1093 
redirection hash table 
alternate, creating 1099 
assigning percentages 1099 
hot spot 1099 
understanding 1098 
refresh bandwidth statistics 981 
refresh bandwidth, configuring 195 
replacing a ProxySG system 950 
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event logging 951 
syslog event monitoring 954 
request modification 514 
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resolving name list, explained 162 
resource use 
disk 1001 
memory 1001 

responder See XML realms 
response modification 514 
restart 

core image 1136 
restarting the ProxySG 
restart options 939 

setting the default system to boot 949 
restoring system defaults 941 
restricting access 315 
revalidate pragma-no-cache 

affects on bandwidth gain 210 
configuring 210 
reverse proxy 
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ProxySG, configuration for 1110 
router configuration for 1110 
WCCP example 1110 
RFC-1323 

configuring 147 
RIP 

configuring 105 
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installing configuration file through CLI 109 
installing configuration file through Management 
Console 105 
parameters 1118 

ProxySG-specific RIP parameters 1119 
using passwords with 1120 
routing 

bypass list 121 
central bypass list 122 
policy-based bypass list 126 
static routes 100 
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RTSP 

port service creating 173 
port services commands 172, 173 
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deleting in Visual Policy Manager 677, 678 
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1170 



Index 



option menus for in Visual Policy Manager 573 
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s 

script tags 708 
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console account 313 
local user list settings, changing 409 
policies for 314, 318 
self-signed certificate 

interactive mode, using 282 
non-interactive create mode, using 283 
sequence realm 

creating a realm through CLI 468 
defining realm server properties through 
Management Console 468 
sequences, troubleshooting 467 
serial console, definition 310 
serial number, configuring 75 
serial port 

password, creating 312 
server_bypass_threshold, using with dynamic 
bypass 127 

server-side bandwidth, enhancing 218 
service information 

enabling automatic 1122 
sending 1124 

set_aut.pl script, using with .htpasswd file 406 
setup console 

password, creating 312 
SGOS 2.x, logs, retrieving 1019 
shell proxies 

$substitutions, using 230 
boundary conditions for 231 
CLI commands, using 234 
policy settings, customizing 230 
Telnet 231 
understanding 229 
show configuration 

Director, using with 1 145 
Simple Network Management Protocol, see SNMP 
SiteMinder, see Netegrity SiteMinder 
SmartFilter 

configuring through CLI 820 
configuring through Management Console 818 
snapshot jobs 

creating and editing 1128 
SNMP 

community strings 958 



enabling 957 
MIB variables 957 
MIBs 957 

reset configuration 957 
traps 959 
SOAP 

XML realms, using with 446 
SOCKS 

commands 175 

compression gain statistics 999 
connections, viewing 998 
creating an installable list for 871 
enabling 225 

gateway configuration 867 
port service, creating 174 
port services commands 226 
SOCKS clients, viewing 998 
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SOCKS gateway 

default sequence, creating 870 
HTTP, using with SOCKS 875 
SOCKS proxy 

bind timeout on accept value 224 
CLI commands 225 
configuring through CLI 225 
configuring through Management Console 224 
connection timeout values 224 
max-connection values 224 
max-idle-timeout value 224 
min-idle-timeout 224 
show socks-proxy 225 
SQUID access log format 892, 1044 
SSH 

client keypairs, importing through CLI 71 
client, managing 69 

configuring through Management Console 68 
host connection, configuring 68 
host keypairs, configuring through CLI 69 
importing client keypairs through Management 
Console 70 

password authentication 313 
setting up 68 
view client-key 72 
view host-public-key 69 
SSH Console 

port service commands 157 
port services, creating 157 
SSH with RSA authentication, not controlled by 
policy 318 
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authentication/ authorization services, using with 
329 

caching behavior, SSL client 291 
cipher suites interactive mode, using 293 
cipher suites non-interactive mode, using 294 
CSR interactive signing request mode, using 277 
CSR non-interactive create signing-request mode, 
using 278 
definition 309 

interactive versus non-interactive modes 282 
LDAP, enabling 363 
log format 893 
no-show keyring option 273 
self-signed certificate interactive mode, using 282 
self-signed certificate non-interactive create 
mode, using 283 

settings, backing up through Director 1145 
show keyring option 273, 302 
show-director option 273, 302 
timeout, configuring 296 
SSL accelerator cards, statistics, viewing 975 
SSL access policy 

Visual Policy Manager reference 582 
SSL certificates, see certificates. 

SSL client 

cipher suite, changing 293 
CLI commands 292 
explained 269 
keyring, associating 292 
managing 291 
SSL Intercept policy 

Visual Policy Manager reference 582 
SSL Proxy 

unintercepted SSL byte statistics 993 
unintercepted SSL client statistics 992 
unintercepted SSL data statistics 991 
SSL proxy 

Add Server Certificate object, using 249 
Add SSL Forward Proxy object, configuring 246 
categorizing hostnames in server certificates 247 
configuring rules 245 

downloading issuer certificates for desktops 243 
explicit mode, configuring 240 
HTTPS content, intercepting 246 
HTTPS traffic, intercepting 238 
limitations 253 

Server Certificate Category object, using 247 
Set Server Certificate Validation object, using 249 



SSL Access layer, using 248 

SSL Intercept layer, configuring through CPL 250 

SSL Intercept layer, using 246 

transparent mode, configuring 239 

understanding 235 

sso.ini, modifying for Novell SSO realm 387 
sso.ini, modifying for Windows SSO realm 357 
static routes 100 
explained 100 
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table, installing through CLI 104 
table, installing through Management Console 
101 
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access logging log size 1014 
access logging, status 1015 
access logging, viewing through CLI 1016 
access logging, viewing through Management 
Console 1013 
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bandwidth gain 979 
cache efficiency 1004 
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cached objects by size 1008 
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data access pattern 1006 
data allocation 1003 
event log 1009 
failover page 141 
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graph scale 973 
HTTP /FTP bytes served 983 
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policy 565 
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system summary 973 
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unintercepted SSL bytes 993 
unintercepted SSL clients 992 
unintercepted SSL data 991 
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access log format 893 
delivery type 730 
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streaming protocols, managing 173 
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subnet mask, configuring with the Management 
Console 87 
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configuring for access logging 927 
configuring through CLI 822 
configuring through Management Console 821 
Reporter, using with SGOS4.X 823 
surrogate credentials, defined 323 
Symantec CarrierScan server 512 
syslog event monitoring 954, 997 
system cache 

clearing 944, 980 
troubleshooting 945, 981 
system defaults, restoring 941 
system summary 973 
system time, see time 75 

T 

TCP NewReno 
configuring 148 
TCP/IP 

configuration, showing 150 
ICMP broadcast echo 148 
ICMP timestamp echo 148 
overview 147 
PMTU, configuring 149 
RFC-1323 147 
TCP NewReno 148 
TCP-Tunnel 

CLI commands 177 
commands, explicit 177 
explicit 176 
overview 175 
port services, creating 176 
Telnet 

banner settings, configuring through CLI 234 
banner settings, configuring through 
Management Console 232 
boundary conditions for Telnet shell proxy 235 
settings customizing 232 
shell proxy, creating service 232 
shell proxy, understanding 231 
Telnet Console 
commands 159 
error message 158 
port service, creating 158 
port service, explained 157, 186 
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automatic download through CLI 832 
automatic download through Management 
Console 832 

time, configuring in the ProxySG 75 
timeout 

configuring for SSL termination 296 
HTTP, configuring 79 
timeout, realm, changing 67 
tolerant request parsing, setting through CLI 199 
transforming active content tags 708 
transparent proxy 
CLI commands 328 
definition 309 
hardware, configuring 259 
IP forwarding 261 

IP forwarding, enabling through CLI 261 
Layer-4 switch, using with 260 
overview 182 

pass-through card, setting up 259 
policy substitution realm, troubleshooting 472 
service, creating 262 
software bridging, setting up 259 
transparent proxy authentication 
configuring 327 

setting options for through CLI 328 
setting options for through Management Console 
327 

transparent redirection, using WCCP 1087 
traps 959 

Trend Micro InterScan VirusWall 512 
troubleshooting 

accept-encoding request header modification 218 
BCAAA service 1033 
browsers 36, 945, 981 
CA-Certificates 280 

cache-control no-transform directive ignored. 219 

compression choices 219 

CONNECT method 326 

explicit proxy and Internet Explorer 220 

forms-based authentication 486 

FTP upload client, upload-now command 921 
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HTTPS and content filtering 839 

HTTPS Console 290 

ICMP host unreachable error message 149 
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multicast, converting from by Windows Media 
749 
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overview 945 
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through Management Console 946 
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changing through CLI 65 
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UTC time 75 
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realm sequence 471 
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